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Bezeichnung: 
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5 Ausfuhrung zur Losung beliebiger gestellter Programmieraufgaben 
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1. Beschreibung: 

1.1 Aufgabenstellung und Stand der Technik: 

5 Allein in Deutschland fehlen auf dem Gebiet der Software-Entwicklung z.Z. 80.000 Mitarbeiter 
und die Entwicklungs-Aufgaben werden immer komplexer. 

Bisiang werden Programme nach gegebener Aufgabenstellung von Software-Entwicklern konzi- 
piert und programmiert. 

Zur Erleichterung der Programmierung gibt es bisiang "Wizards", die mittels Dialog-Fenstern 
10 nach interaktiver Eingabe von Daten des Benutzers grundlegende Teile des Source-Codes nach 
test vorgegebenen Schemata erstellen. 

Ferner werden auch firmenspezifische Skripte geschrieben, die mittels Auslesen von Daten aus 
ASCII-Files einfache stetig wiederkehrende Teile von Sourcecodes generieren. 
In jedem Fall mu& der Benutzer jedoch das erstellende Skript selbst schreiben und vorher die 
15 auszulesenden Daten generieren bzw. im Falle von "Wizards" vorher in Dialogfenstern benutzer- 
definierte Eingaben machen und nach der Ersteliung des Rahmen-Quellcodes die eigentliche 
Funktionsweise der Anwendung selbst ausprogrammieren. Danach mu& noch der Source-Code 
in Maschinencode compiliert werden, bevor er ausgefuhrt werden kann. 
Lernfahig sind solche Programme jedoch nicht. 

20 

Auf dem Gebiet der Kl gibt es neuronale Netzwerke / fuzzy Logic die zwar Expertensysteme 
bilden konnen, die aufcere sensorische Reize aufnehmen und lernfahig in den "Neuronen" dann 
ihre Reaktion darauf entscheiden, also eine Art lemfahige Regelkreise bilden, jedoch konnen sie 
weder planen noch Maschinencode generieren und ausfuhren. 

25 

In 20 W (pat) 12/76 wurde die Generierung kunstlichen Bewufttseins mit rein elektronischen 
Mitteln (Aneinanderreihung von Kameras und Monitoren) versucht - dieses Verfahren hier hat 
damit jedoch uberhaupt nichts zu tun. 

30 Mittels meinem Verfahren wird im Computer eine einfache Form von Bewufctsein erzeugt, das 
anfangs zwar ziellos willkurlich Handelt, jedoch aus den Wirkungen seines eigenen "Verhaltens" 
lernt, um so, nachdem es die Wirkungen aller moglichen Handlungen kennt, spater planend 
selektiv Einzelhandlungen aneinanderzuketten, z.B. um ein vorgegebenes Ziel zu erreichen. 
Jeder Einzelhandlung entspricht hierbei eine Zahl, die, wenn man sie als OpCode (Maschinen- 

35 code), also als direkte Prozessorsteuerungsanweisung, ausfuhrt, entweder einen Fehler (Excep- 
tion) erzeugt, oder eine Veranderung (z.B. der Registerinhalte) bewirkt. 

Das System selektiert mittels geeigneter Analyse- und Bewertungsverfahren Codezusammen- 
stellungen, die dann das gegebene Programmierziel erreichen. 

40 

1.2 Herleitung der Realisierbarkeit und Definition kunstlichen Bewu&tseins: 

1.2. 1 Philosophische Grunduberlegungen: 

(... sind normalerweise kein Bestandteil einer Patentbeschreibung, jedoch fur die Darle- 
45 gung der Realisierbarkeit hier unerlafclich) 

Ware die Voraussetzung des menschlichen Bewufctseins eine Art "Beseelung", die zwischen 
Zygote und Geburt stattfande, konnte man sie aufgrund von Gedankenexperimenten ungefahr 
lokalisieren: 

50 Wurde man gedanklich den Kopf abtrennen und die Halsschlagadern mit sauerstoff- und nahr- 
stoffreichen Blut versorgen, ware das Bewufctsein sicher im Kopf. 

Wurde man nun das Gehirn bis auf die kunstliche Versorgung vollig isolieren, ware zwar auf 
herkommliche Weise kein Informationsflufc zwischen dem Individuum und der Umwelt mehr 
moglich, das "Ich-Bewu&tsein" ware aber sicher noch vorhanden. 
55 Jetzt kann man noch gedanklich die hinteren und seitlichen Grofchirnlappen fur Sehen, Horen, 
Riechen, Schmecken, Gleichgewicht, Sprache und das Kleinhirn abtrennen und es ware nichts 
weiters verloren. 




-3- 

Bei den vorderen Hirnlappen verlore man die Moglichkeit mit vorhandenem Wissen zu rechen 
und bei einigen oberen Hirnteilen ginge Erinnerung verloren, aber das Grund-lch bin ware immer 
noch vorhanden. 

=> Wenn es eine Art "Seele" gabe, lage sie am oberen Ende des Stammhirns. 

5 

Unter Berucksichtigung der gleitenden Evolution hatten dann Primaten aber auch eine "Seele". 
Und andere Saugetiere auch und alle anderen Tiere auch; und Einzeller auch; und Pflanzen 
auch; und somit auch jede einzelne Zelle des menschlichen Korpers selbst. 
=> Es fehlt eine "BewufStseins-" bzw. "Beseelungsgrenze". 
10 Jede Zelle unseres Korpers mufcte eine eigene Seele haben (die evolutionare Spezialisierung 
zur Nervenzelle ist, wie auch bei den prenatalen Zellteilungen, flieftend). 
=> Es gibt keine "Seele". 

=> Bewuf&tsein entsteht im laufe der Evolution zwingend selbsttatig. 
=> im "toten" Molekul der DNA liegt der Bauplan zur Generierung von BewuStsein. 
15 => Bewu&tsein entsteht durch die Bewertung von eigenen Tatigkeiten und deren Auswirkungen, 

mit der Reflexion der Bewertungsergebnisse auf das sich anpassende Bewertungssystem. 
=> Wenn zur Generierung von Bewufctsein keine "Seele" notwendig ist, sondern nur das komplexe 

"Programm" der DNA, dann ist Bewufctsein auch durch ein komplexes reflexives Computer- 

Programm generierbar. 

20 

1.2.2 Realisationsansatz zur Generierung von kunstlichem Bewufctsein: 

Das Handeln aller, auch der einfachsten Individuen dient zur Erfullung ihrer Grundbedurfnisse. 
25 Diese Grundbedurfnisse sind: 

a. ) kein Schmerz: = kein Angriff auf's System und 

b. )kein Hunger := kein drohender Energieverlust 

Ein komplexes Programm, im dem diese Grundbedurfnisse modelliert sind, und das frei Handeln 
30 kann und in der Lage ist, wie ein Kind aus seinen Handlungen reflexiv zu lernen, was seine 
Handlungen bewirken und ob seine Handlungen seine Situation im Bezug auf seine Grund- 
bedurfnisse verbessern oder verschlechtern, baut ein Bewertungssystem auf, plant dann seine 
Handlungen aus dem Erlernten zur Verbesserung seiner Situation und erlangt so Bewu&tsein. 
Scannt es auch einmal seinen eigenen Code, probiert aus, was seine Code-Abschnitte bewirken 
35 und erkennt deren Zusammenhang, erlangt es sogar Selbst-Bewu&tsein, und kann nicht nur 
seinen Code reproduzieren, sondern seinen Code bei der Reproduktion auch bewuSt verandern 
und verbessern, also eine Evolution aufgrund seiner Erkenntnisse beginnen. 



40 1.3. technische Lehre zur Generierung kunstlichen Bewu&tseins: 

1.3.0 Definition der verwendeten Abkurzungen: 

Die Programmierung funktioniert auf jedem Computer mit jedem beliebigem Prozessor und 
45 jedem beliebigem Betriebssystem. Die mit \i indizierten Abkurzungen sind fur die Motorolla- 
Prozessoren MC680xO spezifisch, die mit n indizierten fur die Intel-Pentiums und \\f -indizierte 
kennzeichnen den PowerPC-RISC-Prozessor: 

aq. = aquivalent[e(s)] 

50 ASR^ = Adress Space Register 

BATy, = BAT-Registers 

BC = BitCode: jedes Bit entspricht einem Code und es sind Codekombinationen zulassig. 

CCR^ = Condition-Code-Register ( = Flags: Extension, Negativ-, Zero-, Overflow-, Carry ) 

CISC = Complex-lnstructionSet Computer (z.B. lA^und MC^) 

55 CPU = Central processing Unit = Prozessor 

CRy, = Condition-Register (CR 0..7) 

CR^ = Control-Register 



CTRy, = Count-Register 
DABRy, = Data Adress Breakpoint Register 
DAR^ = Data Adress Register 
DB = DatenBank 
5 DECy, = Decrement-Register 
DR^ = Debug-Register 

DSISR^ = DSI Status-Register zeigt den Grund fur DSI- und Alignment-Exceptions an. 
EA = Effective Adress (direkter Speicherzugriff ohne Register) 
EAR^ = External Access Register 
10 Rseg^ = Segment Register: CS; SS; DS, ES, FS, GS 

EFIags^ = 32-Bit Register mit den System-Flags: IDent-, VirtuallnterruptPending-, VirtuallnterruptFlag- 
AlignmentCheck-, VirtuaL8086Mode-, ResumeFlag-, NestedTask, InputOutputPrivilegeLevel, 
OverflowFlag, DirectionFlag, InterruptEnableFlag, TrapFlag, SignRag, ZeroFlag, 
Auxiliary/Align-CarryFlag, ParityFlag, CarryFlag. 
15 EIP^ = Extended Instruction Pointer PC^) 
ER = Entity Relationship (Datenbankmodell) 
ESP;r = Extended StackPointer (^USP^) 

Exc. = Exceptions #DevideError, #DeBug, NMI IRQ, #BreakPoint, #OverFlow, #BoundRange 
exceeded, #UD (Invalid Opcode), #NM (device not available), #DoubleFault, invalid 
20 #TaskSwitch, Segment #NotPresent, #SS (StackFault), #GeneralProtection, 

#PageFault, #MF (FloatingPoint-Error), #AlignmentCheck, #MachineCheck. 
Exception^. Reset, BusError, AdressError, invalidOpCode, Div/0, CHK, TrapV, 

PrivilegeViolation, Trace, Interrupts, Traps. 
Exception^. System-Reset, Machine-Check, DSI, ISI, Ext.lnterrupt, Alignment, 
25 Program, Floating-Point unavailable, Decrementer, System Call, Trace, Floating- 

Point Assist. 
FFT = fast Fourier-Transformation 
FK = Foreign Key einer ER-Datenbanktabelle 
FPR^ = Floating-Point Register 0.. 31 
30 FPSCR^= Floating-Point Status and Control Register 
GB = GigaBytes = 2 30 Bytes 

GPR = General Purpose Registers: beim Pentium^: EAX, EBX, ECX, EDX; ESI, EDI, EBP; ESP; 

EIP und beim PowerPC^: GPR 0..31 und bei Motorola^ die Daten- und Adress-Reg. 

IA = Intel-Architecture 
35 IRQ = Interrupt-Request 

KB = Kunstliches Bewu&tsein 

kB = KiloBytes = 2 10 Bytes 

Id = Logarithmus dualis = log 2 

LRy, = Link-Register 
40 MB = MegaBytes = 2 20 Bytes 

MSR^ = Model Specific Register 

MSR^ = Machine State Register 

NMI = Non-Maskable-lnterrupt (hochster Interrupt) 

NOP = NoOperartion-OpCode [Maschinencodebefehl ohne Wirkung (aufter IP*/PC A + + )] 
45 OLB = OpCode Lower Byte = letztes Byte im OpCode 

PC^ = Programm-Counter ( = Pointer auf 1 .Byte der Speicherstelle, an der sich der Prozessor 
im Programm gerade befindet, vor der dortigen OpCode-Ausfuhrung) 

PK = Primary Key einer ER-Datenbanktabelle 

PVRy, = Processor Version Register 
50 RISC = Reduced-lnstructionSet Computer (z.B. PowerPC^) 

RTE„ = Befehl: Return from Exception (ladt SR und PC vom Supervisor-Stack) 

SDRV = SDR 1 -Register 

SPRG^ = SPRG 0..3 

SR^ = Statusregister (Flags^: Trace-, Supervisor-, + Interrupt-Maske: l 2 li »o* + CCR-Flags) 
55 SR^ = Segment Registers: CS, DS, SS, ES, FS, GS 
SRy, = Segment Registers 

SRRy, = Save/Restore-Register of Machine-Status 
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SSP^ = Supervisor- Stackpointer (A7 inn Supervisor-Modus) 

TB^ = Time Base Facility: Time-Counter -> 2 64 -1 

TR^ = Table-Register: GDTR, IDTR, LDTR, TR 

USPp = User- Stackpointer (Aderessregister A7 im User-Modus, A7' im Supervisor-Modus) 

5 = = entspricht 

$ = Beginn einer Hexadezimalzahl 

£ = Ergebnis des bitweisen AND uber alle folgenden Werte [ = V 1 & V 2 & .... & V n ] 

S = Ergebnis des bitweisen OR uber alle folgenden Werte [ = | V 2 | .... | V n ] 

T = Anzahl der gesetzten Bits im folgenden Wert [ = (1 &V) + (2&V)/2 + (4&V)/4+ ....] 

10 V" = fur alle anderen ... (nur V = fur alle ...) 



1.3. 1 Verfahrensweise zur Generierung von kunstlichem Bewu&tsein mit einfachen Worten: 

15 Ein Computersystem erlangt Bewufctsein, wenn das aktive Programm, bei dem alle Exception- 
Vektoren abgefangen sind, und Grundbediirfnisse modelliert sind, folgenderma&en verfahrt: 
Generiere eine Zahl und verwende sie als OpCode ( = Operation-Code = Maschinencode-Befehl); 
fiihre ihn aus, werte aus, was er bewirkt hat und speichere die ermittelte Wirkung der Aus- 
fuhrung. Fahre so mit alien Zahlen-»OpCodes mit vielen reprasentativen Anfangsbedingungen 

20 (Register- Werte und Adressregister-Verweisinhalte) fort. 

Benutze dann so die gespeicherten OpCodes, die keine oder nur selten eine Exception verur- 
sachten und werte aus, ob deren Ausfuhrung die eigenen Grundbediirfnisse erfullen, oder ihnen 
abtraglich sind. 

Kette dann die OpCodes aneinander, die die eigene Situation nicht verschlechterten, und werte 
25 die Wirkung dieser Code-Kombinationen aus, und speichere deren Wirkung. 

Plane so Codekombinationen, die das Wohlbefinden bzgl. der Grundbediirfnisse (Modellierung 
siehe 1 .3.5) erhohen bzw. fur das gegebene Programmierziel von Bedeutung sein konnten. 



30 1.3.2 Datenbank des KB-Wissens anlegen: 

Damit das Erlernte des KB-Programms persistent bleibt und die grofcen Datenmengen komfor- 
tabel erreichbar sind, wird eine relationale Datenbank mit den Tabellen und deren Relationen 
gemafc 3.1 angelegt; zwecks Zugriffsbeschleunigung und Speicherplatzersparnis aquivalente 
35 PKs als Cluster, und es werden zwecks Erhohung der Zugriffsgeschwindigkeit fur benotigte 
Non-PK-Spalten weitere Indexe angelegt. Das ER-Diagramm zeigt Fig. 1 . 

Je nach Prozessor und wieviele 32-Bit-Befehle dieser hat, kann die Datenbank sehr groB und die 
Zugriffsgeschwindigkeiten entsprechend langsam werden. Deshalb eignen sich RlSC-Prozes- 
soren eher fur das KB-Programm als CISC-Rechner. Aber auch die CISC-Maschinen, wie die der 
40 IA, benutzen nur bei relativ wenigen Befehlen mehr als 24-Bit, weshalb man mit uber mehrere 
Festplatten gestribeten Tabellen und zusatzlichen Index-Festplatten und mit erhohtem "Verges- 
sen" bei ineffizienten Befehlskombinationen ebenfalls sehr gut arbeiten kann. 
Auf das Speicherplatzproblem wird unter 1.5 eingegangen. 

45 1.3.2.1 Die Register-ldentifikations-Tabelle [RIT '- Fig. 2]: 

In der RIT werden die Daten jedes Prozessor-Registers initial eingegeben: Jedes Register enthalt 
eine Identifikations-Nummer ein zugewiesenes Bit im BitCode ein Zeichen zur Beschreibung des 
Register-Typs, eine laufende Nummer dieses Register-Typs und optional eine Beschreibung des 
Registers. Das Register der Flags (EFIags^/Sfy) hat die Register-ID 0. Die Exception-Vektoren 

50 sind zwar meist keine Register, sondern direkte Adressen im Speicher - um diese wichtigen 
Vektoren ebenfalls identifizieren zu konnen, erhalten sie Redister-IDs mit negativem Vorzeichen, 
die der Exception-Vektornummer entsprechen [wenn Exception-Nr. 0 nicht Reset, sondern eine 
echte Exception ist, um 1 verschoben - dann: Register JD^ -(ExceptionNr + 1)]. 
In Fig. 2b ist fur das Beispiel Motorola dargelegt, wie die RIT aussehen konnte. 
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1.3.2.2 Die Pperations-ldentifikations-Tabelle [PIT - Fig. 4]: 

Wie in der RIT die Register, bekommen in der OIT die wichtigsten Operationen eine Identifi- 
kationsnummer und ein Bit im BitCode zugeordnet. 

Der Operation Type ordnet die Operation in Gruppen ein, die in Fig. 4c beschrieben sind. 
5 Die Operation Mnemonic (braucht nicht exakt zu sein) und die optionale Operation Description 
beschreiben, um was fur einen Befehl es sich handelt. 

1.3.2.3 Die Anfangsbedingungs-Tabeile [ICT (initial conditions) - Fig. 3]: 

Da fur gleiche OpCode-Ausfuhrungen, je nach Anfangsbedingungen, unterschiedliche Wirkung- 
10 en auftreten konnen, werden in dieser Tabelle representative Anfangsbedingungen vorgegeben. 
Fur jede Anfangsbedingungsnummer (hier -31. . + 30) werden fur alle positiven RegisterJDs ein 
Sample von Anfangsbedingungen z.B. nach der in Fig. 3b vorgestellten Funktion generiert. 
Jedoch nur fur alle Register, die mathematisch verwertbare Zahlen enthalten konnen, wie 
Daten-Register, Adress-Register-Verweise und die Adressierung darunter [wg. -(Adr.Reg.)L 
15 Floating-Point-Register und sonstige spezielle Rechen-Register (z.B. MMX). 

Mit Adress-Registern la&t sich zwar auch rechnen, jedoch haben sie immer Werte die an 
Speicheradressen verweisen, an denen dann die vordefinierten Verweis-lnhalte stehen. Somit 
konnen die Anfangsbedingungen fur die Adressregister allenfalls zyklisch durch die Testwerte in 
den Verweisen laufen. 

20 Das StatusyEFIags^Register hat in den hoheren Bytes immer die gleichen Anfangswerte aus 
SAC. actual ' Processor Mode. Bei den ConditionCodes im untersten Byte konnen jedoch die 
Anfangswerte variieren. Mit den Control-, Debug- und Maschinenstatus-Registern, sowie 
sonstigen Spezialregistern wird anfangs ebenfalls kein Unfug getrieben und sie werden immer 
auf die gleichen, Default-Werte gesetzt. 

25 

1.3.2.4 Die OpCode-Register-Tabelle [ORT - Fig. 5]: 

Fur jedes durch die OpCode-Ausfuhrung veranderte Register der aktuellen Anfangsbedingungen 
wird in einer Schleife uber alle moglichen Quellregister ermittelt, durch welche mogliche 
Operation mit welchem Quellregister der Wert im Zielregister entstanden sein konnte. Fur jede 
30 zutreffende Quell-Ziel-Register-Kombination wird ein Tabelleneintrag generiert (bei unitaren 
Operationen ist Register ID source = -1) und fur jede zutreffende Operationsmoglichkeit das 
zugehorige Bit entsprechend der OIT im Operations BitCode gesetzt. Wie alle Felder der ORT 
berechnet werden, ist in Fig. 5 beschrieben. Fig. 19 enthalt die Wertezuweisungs-Algorithmen. 

35 1.3.2.5 Die OpCode-Lern-Tabelle [PL T - Fig. 6]: 

Die OLT stellt eine Zusammenfassung der Auswirkungen des aktuellen OpCodes unter den 
verschiedenen verwendeten Anfangsbedingungen dar. 

In den ersten 6 Spalten werden Informationen uber fatale Auswirkungen dieses OpCodes 
gesammelt. Dann kommt die Differenz des Programmzahlers nach der OpCode-Ausfuhrung zum 
40 Wert davor und nun die Condition-Codes, die einen Sprung ausgelost haben konnten [redundant 
\CX .Register ValueKRegisterJD = 0)]. 

Danach kommen in Register changed BitCode und Register source JBitCode die Bits aller 
moglichen Ziel- und Quell-Register aus den zugehorigen ORT-Eintragen und in max Pperation- 
BitCode und min Pperation _BitCode die bitweise gePReten und ge>4A/Deten BitCodes der 
45 ORT. Pperations BitCode -Eintrage. 

Die Dauer und der Zeitpunkt der OpCode-Ausfuhrung werden gespeichert und in aim valuation 
wird entsprechend V FT. Valuation Functioni ADT. aim Valuation FunctionID ) bewertet, wie 
wertvoll der OpCode unter diesen Anfangsbedingungen fur die Programmierzielerreichung war 
(Wertezuweisungen nach Fig. 20). 

50 

1.3.2.6 Die PpCode-Basis-Tabelle fPBT - Fig. 7 J: 

Die OpCode-Basis-Tabelle beschreibt die ermittelte Gesamtwirkung eines OpCodes unter alien 
verwendeten Anfangsbedingungen. In Fig. 21 ist dargelegt, wie die Auswertung (Fullen der 
Spalten) erfolgt, um einen "Steckbrief " des OpCodes zu erstellen. 
55 Die OBT enthalt das Resumme aller Ausfuhrungen dieses OpCodes und ist spater beim 
zielgerichteten planen von Codekombinationen wichtig. 



1.3.2.7 Die Kombinations-Register-Tabellen [CRT(i) - Fig. 8]: 

Die Kombinations-Register-Tabellen werden dynamisch angelegt und entsprechen der der ORT, 
mit dem Unterschied, date hier die Wirkungen von OpCode-Kombinationen analysiert werden. 
CBT(1) = OBT, CBT(2) hat einen OpCode mehr im PK, CBT(3) hat 3 OpCodes im PK f u.s.w. 

5 

1.3.2.8 Die Kombinations-Lern-Tabellen fCL T(i) - Fig. 9]: 

Hier gilt das gleiche analog der CRT(i). Die CLT(i) geben die Wirkung der OpCode-Kombination 
bei den verwendeten Anfangsbedingungen wieder. Jetzt gewinnt auch das Feld CL T(i). gradient- 
aim valuation an Bedeutung. Wahrend es noch bei der CLT(1) = OLT identisch aim valuation 
10 ist, enthait es bei den CLT(i>2): CLT(i). aim valuation - CLT(i-1 ). aim valuation (Fig. 20 unten). 

1.3.2.9 Die Kombinations-Basis-Tabellen [CBT(i) - Fig. 10]: 

Die CBT(i) geben folglich das Resumme der Wirkung der OpCode-Kombination wieder. Die 
Wertezuweisungen erfolgen nach Fig. 21. Die gerade hochste CBT(n) ist die CPT (Kombinations- 
15 Plan-Tabelle = Entstehungsort des Losungsprogramms). 

Ergibt A DT. aim full filied Flag Function (CPT-PK) = 1 (TRUE), wurde gerade ein Losungsprogramm 
der gestellten Programmieraufgabe gefunden, und es wird in der AST eingetragen. 

1.3.2.10 Die Ziellosungs-Tabelle [AST (aim solution) - Fig. 1 1J: 

20 Die AST enthait fur jede gestellte Programmieraufgabe die Losungsprogramme, deren Programm- 
langen, die Ausfuhrungszeiten und die je benutzten Register und Operationen. 

1.3.2.11 Die Ziel-Beschreibungs-Tabelle [APT (aim description) - Fig. 12]: 

Die ADT ordnet jedem Programmierziel eine Indentifikationsnummer zu, eine Kurzbeschreibung, 
25 die BitCode-Kombinationen der zu verwendenden Quell- und Ziel-Register, die Register und 
Operationen, die im Losungsprogramm nicht verwendet werden sollen, fruhere Losungspro- 
gramme, die mitverwendet werden konnten und eine Funktion, die TRUE ausgibt, wenn die 
OpCode-Kombination fur die Ein- und AusgabeRegister eine Losung der gestellten Aufgabe dar- 
stellt, sowie eine Identifikation der Ziel-Annaherungsfunktion der VFT (u.a. v. o.g. aim fulfilled- 
30 Flag Function abhangig), die die Zielnahe der akt. OpCode-Kombination ( = CPT-PK) bewertet. 

1.3.2. 12 Die Funktion-ldentifikations-Tabelle [FIT - Fig. 13, 14]: 

In der FIT werden Teiifunktionen, die fur die Zusammenstellung der Energie-Bewertungsfunktion 
verwendet werden konnten, zur Verfugung gestellt. 
35 Sie wird in 2 Variationen vorgestellt: 

a. ) fur die Erstellung einer dynamischen Bewertungsfunktion in SQL, 

b. ) fur die Erstellung einer dynamischen Bewertungsfunktion in Maschinensprache. 

Der veranderliche Aufbau einer Bewertungsfunktion ist in SQL viel einfacher zu bewerkstelligen, 
jedoch sind die Ausfuhrungszeiten entsprechend langsam und es muft nach jeder Zusammen- 
40 stellung neu geparsed werden. 

Zukunftig soil auch die Bewertungsfunktion gleich in Maschinencode zusammengestellt werden. 
Das auch hat den Vorteil, daft das KB-Programm manche geloste Programmierziele als FIT- 
Teilfunktionen fur die Zusammenstellung der Bewertungsfunktion weiterverwenden kann. 

45 1.3.2. 13 Die Bewertungs-Funktions-Tabelle [VFT (valuation f.) - Fig. 15]: 

In der VFT liegt das dynamische Bewertungssystem im Bezug auf das eigene " Wohlbefinden" 
(Energie-Register) und der Programmierzielnahe. 

Die VFT. Valuation Functioni Type='E\ SAC.Energy Valuation FunctionJD ) bewertet energie- 
spezifische Handlungen und die Valuation Functioni Type='A', SAC.Aim_ValuationJ=unctionlD ) 

50 die Programmierziel-Erreichungsnahe. 

Die VFT .Function JD Chain enthait die Verkettung der Function-ID*s, also die Teilfunktions-Ausfuhr- 
ungs-Reihenfolge: Hier bewirkt NUM, date der nachste Wert eine Byte-Zahl ist, VALUE, daft der 
nachste Wert die LfdNr der CLT(n)-Spalte ist, der ein Wert entnommen wird, EREG die RegisterJD 
des Energie-Registers, S/D_REG der Wert aus der ADT.all source/dest Registers BitCode und AIM F 

55 das Ergebnis aus der ADT.aim_fulfilled_Flag_Function. Die unitaren Operationen wirken auf das letzte 
Ergebnis und die binaren auf die letzten 2 Ergebnisse aus der FunctionJD Chain. 
Bei jeder Anpassung, Erweiterung oder sonstigen Verbesserung dieser Bewertungsfunktionen 



• 
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wird die Valuation Function ID incrementiert und ein neuer Eintrag mit der veranderten 
Valuation Function generiert und alle Bewertungsfunktionen in ihrer Effizienz neu bewertet: 
VFT .Valuation Function value = SfKC.Energy/Aimjself valuation _Func(...)], um einen Effizienz- 
Gradienten als Referenz fur weitere Verbesserungen zu haben. 
5 Die Funktionsweise des dynamischen Bewertungssystems ist unter 1.3.7 beschrieben. 

1.3.2. 14 Die Statuszeile des KB-Programms [SAC (state artificial consciousness) - Fig. 16]: 
Diese Tabelle hat keinen Key und nur einen Eintrag. Er enthalt die Statusinformationen des KB- 
Programms und zwei Selbstbewertungs-Funktionen, die Effizienz der Energie- und der 
10 Zielannaherungs-Bewertungsfunktionen der VFT anhand ihrer gelieferten Ergebnisse bewertet. 
Diese Selbstbewertungsfunktionen werden, im Gegensatz zur Energie- und Zielnahe- 
Bewertungsfunktion, vom Programm selbst nicht mehr verandert, konnen jedoch vom Benutzer 
angepaftt werden. 

15 1.3.2.15 Die Energie-Lern- Tabelle [EL T - Fig. 7 7]: 

In der ELT werden Daten iiber alle energiespezifischen Handlungen der akt. Anfangsbeding- 
ungen, also uber alle OpCodes und Code-Kombinationen, die das letzte Datenregister betreffen, 
gesammelt. 

Die Wertvolligkeit der energiespezifischen Handlung wird nach ELT '.Energy valuation = 
20 VFT. Valuation Functioni SAC. Energy Valuation Func ID ) bewertet. 

1.3.2. 16 Die Energie-Basis- Tabelle [EBT - Fig. 18]: 

Ahnlich wie in den CBT(i), werden in der EBT die Auswirkungen einer energieandernden Code- 
Kombinationen, als Resumme aller Anfangsbedingungen, gesammelt. 

25 

1.3.3 Das System in den vorbereitenden Anfangszustand bringen: 

Um das System spater wieder ohne neues booten in den ursprunglichen Zustand versetzen zu 
30 konnen, mussen einige Pointer ( = Zeiger = Adressen) gesichert (zwischengespeichert) werden. 
Danach werden die Exception-Vektoren mit eigenen Abfang-Routinen belegt, da das System 
anfangs Zahlen willkurlich als Maschinencode generiert und ausfuhrt, obwohl viele dieser 
Zahlen als OpCode unzulassig sind oder aufgrund der gerade gewahlten Anfangsbedingungen 
Fehler verursachen. Systemabsturze waren die Folge, wenn man nicht alle Exception-Vektoren 
35 abfinge. 

Will man das bewufttseingenerierende Programm laufen iassen, muB man also, im Falle, daft es 
als einziges Programm im Computer laufen soil: 

a. ) das Multitasking abschalten, in dem man dieses entweder mit einer Betriebssystemroutine 
40 disabled oder indem man die IRQ-Maske des Prozessors auf NMI setzt. 

b. )alle System-Exception-Vektoren sichern. 

dalle Sytem-Exception-Vektoren des Prozessors auf eigene Behandlungsroutinen umlenken. 
oder wenn man es spater einmal neben anderen Programmen und vielleicht auch weiteren k.B.~ 
Programmen parallel laufen Iassen will: 
45 a') die eigene Task-Prioritat etwas erhohen. 
b'lalle Task-Exception-Vektoren sichern. 

c')alle Task-Exception-Vektoren des KB-Programms auf eigene Behandlungsroutinen umlenken. 

d.)das Statusregister^ (=EFIag%) und den User-Stackpointer sichern. 
50 e.) die Werte der anderen Adressregister und die der Datenregister sichern. 

f. ) die Werte der Segment-, Control-, Debug- und Spezialregister sichern. 

g. )manche Exception-Vektoren auf besondere Abfangroutine setzen, die berucksichtigt, daft 

zusatzliche Daten (z.B. bei Adressfehler: zusatzlich Zugriffsadresse + Opcode) auf den Super- 
visor-Stack geladen werden. 
55 h.) Privilege-Violation-Exception-Vector auf besondere Abfangroutine setzen. 

i.) einen Trap-Vektor auf eine Routine setzen, bei der im Supervisor-Modus fortgefuhrt werden 
soil. 
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j.) diesen Trap ausfuhren (CPU schaltet sich jetzt in den Supervisor-Modus und macht ab dieser 

Trap-Vektoradresse weiter). 
k.) Trace-Exception-Vektor auf eigene Trace-Routine zur Wirkungs-Analyse setzen. 
I.) Flags des ersten Word auf dem Supervisor-Stack so setzen, date beim Laden des SR vom 
5 SSP das Trace-Flag und die IRQ-Maske-»NMI gesetzt werden (bei Motorola ist das #$8700), 

denn wahrend des folgenden Basis-Lernens soli noch kein Interrupt moglich sein. 
Siehe hierzu Fig. 24a. 



10 1.3.4 Basis-Lernen aus den Ausfuhrungen alter OpCodes: 

1 .3.4. 1 OpCode generieren und ausfuhren: 

a. ) 32-Bit-Zahl als OpCode generieren, angefangen bei $0000.0000, im weiteren Verlauf immer 
um 1 hochzahlen [dabei kann man von vorn herein die OpCodes uberspringen, die offen- 
sichtlich Unfug machen wurden (siehe BitCodes des CPU-Befehlssatzes)]. 

b. JDaten- und Adress-Register, sowie die AdressRegister-Verweislnhalte und die Verweis- 
Inhalte ein DWord darunter auf vordefinierte Testwerte laden und die ConditionCodes in 
EFIags^CR^ loschen. 

c. ) Den generierten OpCode an die Teststelle im Speicher schreiben. Hinter der Teststelle mu& 
noch mit ausreichend NOP-OpCodes (oder besser mit Nullen, wenn diese der Mnemonic "ORI 
#0, Reg.0" entsprechen) aufgefullt werden, da es sich um einen langen Befehl handeln 
konnte und auch der Fall der Trace-Bit-Loschung mitberucksichtigt werden mu& (dahinter 
steht die Trace-Bit-Cleared Abfangroutine). 

d. )Supervisor-Stack-lnhalt so setzen, daR beim Rucksprung aus dem Supervisor-Modus das 
Statusregister mit geloschtem CCR, IRQ-Maske auf NMI, Trace-Bit gesetzt und Supervisor- 
Bit[Maske] geloscht, geladen wird und das dahinter befindliche Langwort die Test-Adresse 
darstellt. Rucksprung aus Supervisor-Modus (RTE^) ausfuhren: das EFIags^/Status-Rgister^ 
wird mit o.g. Werten initiiert und der IP^PC^ mit der Testadresse geladen und der an der 
Teststelle befindliche OpCode ausgefuhrt. 

• Ist jetzt eine Exception (au&er Trace) aufgetreten, wird die Exception kurz grafisch 
angezeigt und bei der Generierung des nachsten OpCodes fortgefuhrt. Diesen OpCode 
kann das Individuum vergessen. [Achtung: bei manchen Exceptions tritt wegen Trace 
eine Kombination des Exception-Handlings auf.] 

• Tritt weder Trace, noch eine andere Exception auf, wurde das Trace-Bit geloscht (sollte 
bei Einzel-OpCodes nie auftreten) und die hinter der Teststelle befindliche Abfangroutine 
wird ausgefuhrt. 

• Bei Trace-Exception (Normalfall) wurde ein benutzbarer OpCode generiert, dessen Aus- 
fuhrungs-Auswirkungen jetzt analysiert werden mussen. 

40 1.3.4.2 Analyse der OpCode-Auswirkung und Speichern der Ergebnisse: 

a. ) Das EFIags^/Status-Register^ und die Daten- und Adressregister, sowie Adressregister- 

Verweisinhalte und die Verweisinhalte des DWords vor den Adressregistern und den User- 
Stackpinter zur Analyse speichern. 

b. ) Uberprufung der eigenen Maschinencode-CheckSum des aktiven KB-Programms und der 
45 CheckSum der inaktiven Kopie im RAM (je ohne Test-OpCode-Speicherstelle): Bei Check- 

Sum-Anderung hat sich das Programm bei der Ausfuhrung "verletzt" (Programmteile selbst 
uberschrieben). Dann das entsprechende Corrupt-Flag in der Tabelle setzen. Bei Verletzung 
der aktiven Version in die inaktive Kopien springen, dann den Code vergleichen und die 
korrupten Bytes durch Code der unverletzten Version ersetzen. 

50 c.)Die Supervisor-BitMaske des gesicherten User-Stackpointers auf Stack prufen: War der 
Prozessor vor Ausfuhrung der Exception im Supervisor-Modus (obwohl er bei der Test- 
OpCode-Ausfiihrung im User-Modus war), ist eine Kombination von der normalen Trace- 
Exception mit einer niedrig priorisierten Exception aufgetreten [z.B. bei Motorola Div/0-, 
Trap- oder Chk-Exception (im 68000er Handbuch nicht dokumentiert!)]. D.h. der Prozessor 

55 holte erst den Exception-Vektor des gerade aufgetretenen niedriger priorisierten Fehlers und 
lud das Statusregister und den Programmzahler auf den Supervisor-Stack und sprang dann 
noch wahrend dieser prozessorinternen Routine, noch vor Beginn der Exception-Routine in 



20 



25 



30 
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die weitere Trace-Exception-Routine, wodurch wieder Programmzahler und das Status- 
Register auf den Supervisor-Stack geladen wurden. 

Mittels der auf dem Supervisor-Stack gesicherten Supervisor-Bits des Statusregisters ist nun 
feststellbar, date vor Trace bereits eine Exception auftrat und durch Vergleich des zweiten 
5 auf dem Supervisor- Stack gesicherten Programmzahlers mit den niedrigpriorisierten 
Exception-Vektoren ist nun die ursprungliche Exception vor Trace ermittelbar, deren 
Exception-Nummer abgespeichert wird. 

d. ) Vergleich des IP^/PC^ auf dem Supervisor-Stack mit der Test-OpCode-Adresse: Wurde der 

IP^/PC^ erniedrigt, blieb unverandert oder um einen Wert grofcer als der langstmogliche 
10 OpCode erhoht, war es ein Sprung. 

Wurde er um mehr als 4 Bytes erhoht, war es ein langer Befehl oder ein kurzer Vorwarts- 
sprung - die Differenzierung ergibt dann daraus, ob Register verandert wurden. 
Dieses Analyse-Ergebnis wird wieder abgespeichert. 

e. ) Vergleich des EFIags^/Status-Registers^ und aller Registerinhalte und der AdressRegister- 
15 Verweisinhalte, und der AdressRegister-Verweisinhalte einer max. Adressierbarkeitslange 

darunter [wg. -(Adr.Reg.) ] mit den Original-Werten. 

In einer BitMaske wird nun geflaggt, welche Register geandert wurden und es wird analy- 
siert, welche Operationen mit welchen Quell- und Zielregistern stattgefunden haben kdnnten 
(hierbei Anderungen das EFIags^/SR^ beachten) und das Ergebnis wird in der ORT und OLT 
20 gespeichert (siehe Figs. 5, 1 9;6,20) und die OBT aktualisiert (Fig. 7, 21). 

f. ) Bei Sprungen Analyse des EFIags^/SR^, ob der Sprung bedingungsabhangig war. 

1.3.5 Realisierung der Grundbedurfnisse: 

25 

1.3.5. 1 Realisierung kunstlichen Schmerzes: 

Schmerz wird durch die Verletzung des Systems verursacht. Der ursprunglichste Schmerz in der 
biologischen Evolution kommt bereits beim Einzeller vor und ist die Verletzung der DNA im 
Zellkern. Ist die DNA verletzt, mu£ sich der Einzeller unter Aufbringung seiner Ressourcen die 
30 Zeit nehmen, seine DNA zu reparieren. Er tut dies, indem er die fehlenden Aminosauren in der 
defekten Doppelhelixhalfte durch komplimentare Basen der intakten Doppelhelixhalfte kompli- 
mentar ersetzt. 

Das KB-Programm wird doppelt in's RAM geladen. Fuhrt das KB-Prg. (oder ein anderes) einen 
Befehl aus, der seinen aktiven oder inaktiven Code im Speicher uberschreibt, wird es also in der 

35 aktiven oder inaktiven Form verletzt, kann es diese Verletzung anhand einer Anderung seiner 
CheckSum erkennen und mufc sich nun die Zeit nehmen, bei Verletzung des aktiven Codes nun 
in den bisher inaktiven aquivalenten Code zu springen und dann beide Codes 32-Bit weise 
Overgleichen und an der Stelle der Ungleichheit das DoubleWord seines Codes mit 
unveranderter CheckSum an die verletzte Stelle des Codes mit veranderter CheckSum 

40 schreiben, um sich zu heilen. 

1.3.5.2 Realisierung kunstlichen Hungers: 

Hunger ist drohender Energieverlust. Energie wird in den Zellen u.a. durch Umwandlung von 
Adenosintriphosphat in Adenosindiphosphat erzeugt. Die Energie zurrv Aufbau von Adenosintri- 
45 phosphat aus Adenosindiphosphat wird durch Verbrennung von Glucose gewonnen. Fehlende 
Energie macht in den Zellen den Stoffwechsel und somit jede Handlung, Reaktion auf Schmerz 
oder die Selbstheilung bei Verletzung unmoglich. 

Die "Energiemenge" des KB-Programms la&t sich durch die Hone eines Werts in einem 
Datenregister modellieren. Es ware nun moglich, Hunger durch abnehmende Stromversorgung 
50 des Prozessors durch externes auslesen dieses Datenregisters und Erhohung eines Ohmschen 
Widerstandswerts der Prozessorstromversorgung zu realisieren. Eine weniger authentische, 
hardwareungebundene Losung ist auch moglich: 

Fehlende Energie ist dem Lernprozess abtraglich. Bei mafcigen Werten in o.g. Datenregister 
treten Fehler beim Lernen aus den OpCode-Ausfuhrungen auf. Bei geringen Werten ist das 
55 Lernen aus OpCode-Ausfuhrungen nicht mehr moglich und kleinste Werte in diesen Daten- 
register lassen gespeichertes Wissen vergessen. Ist der Wert auf null tritt zusatzlich Schmerz, 
also EigenCode-Verletzung auf. 



Das KB-Programm mu& also bei Hunger OpCodes finden und ausfuhren, die den Wert dieses 
Datenregisters erhohen. 

Die abnehmende Energie, also das entstehen von Hunger, wird dadurch simuliert, daft das KB- 
Programm selbst nach jeder Handlung ( - OpCode-Ausfuhrung) dieses Register um 1 erniedrigt. 

5 

1.3.6 Plan en nach den Kriterien des Bewertungssystems: 

Hat das Individuum alle ihm mdglichen OpCodes getestet und sich die Auswirkungen der 
10 verwendbaren Befehle gemerkt, kann es aufgrund seines Wissens zur Befriedigung seiner 
Grundbedurfnisse und zur Erreichung von Programmierzielen nun lernen zu planen: 
Hierfur reiht es OpCodes zu Kombinationen aneinander, fuhrt diese unter alien Anfangsbeding- 
ungen aus und wertet wieder aus, was diese Code-Kombination bewirkt hat. 
Da meist langere Kombinationen zur Ziellosung notwendig sind, plant es die Codezusammen- 
15 stellung, in dem es zielgerichtet nur die Codes zur Kombination benutzt, die keinen Schaden 
anrichteten, also nicht den eigenen Code uberschrieben und am besten uberhaupt keine RAM- 
Schreibzugriffe machten, ferner keine verbotenen Register bzw. Operationen benutzten 
( A DT . unused Registers BitCode | A DT . unused Operations BitCode ) und auch keine Exceptions 
verursachten, wo man bei Divide-Error und Overflow-Exception toleranter sein sollte. OpCodes 
20 die gewunschte Ziel- und Quellregister benutzen, werden wiederum bevorzugt kombiniert 
(ADT. all source/dest Registers BitCode) . 

ADT .aim fulfill ' valuation mode bestimmt, ob die Bewertungsfunktion in SQL oder direkt in 
Maschinensprache vorliegt. Fur den normalen Anwender ware die langsamere SQL-Variante 
benutzerfreundlicher und der Spezialist wird fur komplexere Aufgaben sicher schnelle 
25 Zielerfullungs-Bewertungsfunktionen in Maschinensprache bevorzugen. 

7.3.7 Das dynamisch-reflexive Bewertungssystem: 

30 1.3.7.1 Programmierzielnahe-Be wertung: 

Die ADT .aim full filled _Flag_Function( AimJD ), gibt TRUE zuriick, wenn das Programmierziel 
erreicht wurde und die VFT .Valuation Function^ Type='A', ADT .aim Jullf Med Flag Function, 
VFT .Function ID Chain ), liefert einen signed-byte Wert, der besagt, wie nah die aktuelle 
CLT(n)-OpCode-Kombination bei den gegebenen Anfangsbedingungen der Ziellosung kommt. 

35 Das Ergebnis wird in CLT(n). aim valuation gespeichert und bildet im Vergleich mit der letzten 
CLT(n-1 ).aim valuation den Gradient CLT(n). gradient aim j/aluation. 

Da das Ldsungsprogramm jedoch fur alle Anfangsbedingungen funktionieren muft, werden die 
maximale und die durchschnittliche Wertvolligkeit der OpCode-Kombination als Mittelwert aller 
Anfangsbedingunen in CBT(n). max aim valuation bzw. CBT(n). avg aim valuation abgelegt; die 
40 Gradienten zu den Werten der letzten CBT(n-1) bilden CBT(n). max grad aim valuation und 
CBT(n). avg jgrad aim valuation. 

Bei jeder Bewertung wird VFT .boundary value counter hochgezahlt, wenn ein Grenzwert von 
-128 bzw. +127 vergeben wurde und Equivalent low value counter, wenn eine Bewertung 
zwischen -16 und +15 auftrat. 

45 Anhand dieser statistischen Daten und einer exakten Auswertung aller CLT(i). aim valuation, 
z.B. indem man ein kleines Wertebereichs-Fenster durchlaufen la&t und die Eintrage je 
Fensterbreite und -offset zahlt, be wertet die $ AC. Aim Self Valuation Func nach jeder 
Programmierziel-Erreichung der Bewertungs-Ergebnisse der VFT .Valuation Function und somit 
deren Effizienz. Fallen z.B. die meisten Bewertungsergebnisse auf die Grenzwerte, war die 

50 Bewertungsfunktion zu steil und sie mute abgeflacht werden, also in der VFT .Function ID Chain 
mehr Elemente mit negativem FIT .Function Flatten enthalten. Umgekehrtes gilt, wenn die 
meisten Bewertungsergebnisse einen hohen VFT .low value counter -Wert verursachten. 
Nach jeder Programmierzielerreichung lauft somit eine Selbstbewertung der Bewertungsfunktion 
ab und ein weiterer Programmierschritt der selbstprogrammierung der Bewertungsfunktion: 

55 Zur Bewertungsfunktion kommen neue Elemente hinzu und manchmal mufc auch eines wegge- 
lassen werden und der Steilheitsgrad wird angepafct. Dann wird die Bewertung erneut 
vorgenommen und uberpruft, ob die veranderte Bewertungsfunktion einen besseren 
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Wertebereich geliefert hatte. War der neue Wertebereich nach der Selbstbewertung durch 
SAC. Aim Self ' Valuation Function schlechter wird die Anderung der Bewertungsfunktion 
verworfen und eine andere Anderung versucht. Verbesserte die Bewertungsfunktionsanderung 
den Wertebereich, wird die nachste Verbesserung versucht und wenn die Selbstbewertung 
5 einen guten Wert ergibt, mit der nachsten Programmieraufgabe fortgefahren. 

1.3.7.2 Dynamische Energiebewertungsfunktion: 

Das energiespezifische Bewertungssystem ist folgendermaSen dynamisiert: 

O.JDa die Ergebnis-Werte des Bewertungssystems hier auf den Wertebereich von signedbyte 
10 beschrankt sind, wird die Bewertungsfunktion in eine Rahmenfunktion eingebettet: 
Bewertungsergebnis := MIN[ MAX( Bewertungsfunktion, -128), +127) ] 
1 .)Die Bewertungsfunktion O-ter Ordnung ist "wie satt bin ich nach der Handlung ?": 
Bewertungsfunktion(O) := MIN[ MAX( Energy after , -128), +127) ] 

2. ) Die Bewertungsfunktion 1-ter Ordnung ist "wieviel satter bin ich nach der Handlung ?": 
15 Bewertungsfunktiond ) := MIN[ MAX( Energyafter - Energy before, -128), +127 ] 

3. ) Da das Energieregister vom Typ unsigned integer (DWord) ist, waren die Rahmen bei der 

Bewertung zu schnell erreicht, deshalb entweder geringer Logarithmus oder: 
Bewertungsfunktion! 2) := MIN[ MAX[ SQRT( Energy after - Energy before ), -128], +127] 

4. ) Jetzt ergaben sich falsche Werte bei negativen Energie-Gradienten, deshalb 3.Wurzel oder: 
20 Bewertungsfunktion(3) := MIN[ MAX[ SGN( EnergyGrad )*SQRT( EnergyGrad ), -128], +127], mit 

EnergyGrad — Energy after - Energy before 
Moglicherweise ware auch die Funktion Y 2 -SGN( EnergyGrad ) SQRT( SQRT( EnergyGrad ) ) besser, 
da diese exakt bis zu den Rahmenwerten reicht. Aber vielleicht werden auch die Rahmenwerte 
fast nie erreicht und eine feinere Gliederung um den Nullwert ware viel wichtiger. 

25 Dies hangt davon ab, wie oft die Rahmenwerte erreicht werden und wie viele Energie- 
Gradienten kleine Werte aufweisen. Vielleicht mulX auch der Ergebniswert starker gewichtet 
werden und eine Gradientbewertung reicht allein nicht aus; ferner muB mitberucksichtigt 
werden, wieviele/welche weitere(n) Register neben der Energieveranderung mitbetroffen sind 
und welche OperationsTypen ausgefuht wurden, u.s.w., und schlieSlich die Ausfuhrungszeit 

30 der Bewertungsfunktion selbst. Deshalb mute sich das energiespezifische Bewertungssystem im 
Laufe der Zeit verfeinern und anpassen (wie bei intelligenten biologischen Lebensformen). 
In dynamic embedded [PL/JSQL ist das verandern und neu parsen der als String gespeicherten 
Bewertungsfunktion kein Problem. Wegen der Ausfuhrungsgeschwindigkeit und der Implemen- 
tationsfahigkeit voriger Aufgabenlosungen soil jedoch die Bewertungsfunktion zukunftig in 

35 Maschinensprache erfolgen. 

Die Programmieraufgabe der Verbesserung der energiespezifischen Bewertungsfunktion wird 
ebenfalls nach jeder Programmierzielerreichung angegangen. 

Bewertungssystem und Bewertungsergebnisse sind immer reflexiv. 

40 

1.3.8 Selbstbewu&twerdung, Reproduktion und Evolution: 

Durch den Selbstreperaturvorgang bei Schmerz kennt das Prograrnm seine Lage im Speicher. Es 
45 kann nun die Auswirkungen seiner eigenen OpCodes der Reihe nach testen. Erkennt es spater 
einmal die Gesamtauswirkung seiner ganzen Codelange, wird es sich seiner selbst bewu&t, 
kann seinen Code replizieren und aufgrund seines Wissens hierbei bewufct verandern (z.B. das 
lastige Erniedrigen des "Energie" -Registers entfernen). Die intelligente Reproduktion ist der der 
genetischen Reproduktion weit uberlegen, da bei letzterer nur auf vorhandene DNA zuruckge- 
50 griffen werden kann und hier der eigene Programmcode bewufct beliebig verandert und erweitert 
wird. 
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1 .4. Programmieraufgabenstellung und Beispiele der Zielerreichung 

Dem KB-Programm wird nun eine beliebige Programmieraufgabe gestellt, und es erhalt in 
AD1 .aim fulfilled Flag Function einen Prufungsalgorithmus, mit dem es uberprufen kann, ob es 
5 die Aufgabe erfullt hat. 

Seine Aufgabe ist nun, ein Programm zu schreiben, dafc die gestellte Aufgabe lost. 



1.4. 1 Beispielaufgabe 1: Erstellung eines Programms zur Berechnung des Mittelwerts: 

Eine sehr einfache, aber leicht nachvollziehbare Aufgabe fur das KB-Programm konnte sein: 
"Schreibe ein Programm, das den Mittelwert 2er beliebiger Integer-Zahlen berechnet." 
Das KB-Programm hat diese Aufgabe erfullt, wenn die Differenz von der Ergebnis-Zahl zur 
kleineren Zahl gleich der Differenz von der Ergebnis-Zahl zur groBeren Zahl ist, und dies fur 
beliebig viele Eingabe-Zahlenpaare zutrifft. 

Das KB-Programm kennt jedoch den Befehlssatz des Prozessors nicht - ihm stehen lediglich die 
OpCodes zur Verfugung, die keinen Schaden verursachten und es kennt einen Teil deren 
Wirkungen bei einigen unterschiedlichen Anfangsbedingungen. 

Durch das Corruption-Healing oder das Energie-Register kennt es bereits einfachste Aufgaben 
wie "fuhre keine Handlung aus, die Schmerz verursacht" oder "fuhre Handlungen aus, die mich 
satt machen". 

Zur Erreichung von wirtschaftlichen Zielen benotigt es nun Bewertungsvariablen, die ihm Dinge 
sagen wie 

a. )Wieviel naher oder weiter weg vom Ziel hat mich diese Befehlskombination gebracht (das 
jeder einzelne Befehl davon gegenteilige Wirkung haben kann, ist hier nicht von Interesse). 

b. ) Wieviele Taktzyklen habe ich fur die Losung verbraucht. 

c. ) Wieviele Bytes ist mein Programm lang (wieviele OpCodes mit welchen Langen). 
Diese Tabellen-Spalten sind: aim valuation; cycles of execution; OpCode length or Jump. 

30 Die Eingabe-Werte der Beispiel-Aufgabe seien in den ersten beiden Datenregistern (EAX^, EBX K 
bzw. DO^DI^y bzw. GPRO^, GPR1 V ), i.F. RO und Rl. 

Der Ausgabe-Wert soil im dritten Datenregister (ECX^I D2^| GPR2 4> ) i.F. R2 erfolgen. Ist die Auf- 
gabe fur beliebige Eingabewerte gelost, ist das Programm fertig, da es sich wegen der Ein- und 
Ausgabevariablen um eine Funktion handelt. Bei mehreren Losungen wird die mit den wenigsten 
35 verbrauchten Taktzyklen gewahlt. 

Die aufgabenspezifische Zielerreichungs-Bewertungs-Funktion, die zur Berechnung von 
OLT .aim valuation benotigt wird, ist somit in diesem Beispiel: 

A D T . aim fulfilled Flag Function ( Mittelwert mit o.g. Registern ) = [(R2-R0) = (Rl -R2)] 

Hier kann jedoch das Problem auftreten, daft ein Eingabe-Wert gerade und der andere ungerade 

40 ist und die Aufgabe deshalb mit dieser Eingabe-Kombination somit manchmal keine Losung hat. 
Das KB-Programm wird mehrere Losungs-Programme finden und sich fur dasjenige entscheiden, 
das am wenigsten Taktzyklen verbraucht, also das Ergebnis am schnellsten liefert. 
Moglich ware bei CBT(3) folgendes Losungsprogramm: MOV R0,R2 ; ADD R1 ,R2 ; SHR R2 
(naturlich im Maschinencode des verwendeten Prozessors - beim Pentium ware das die 48-Bit- 

45 Zahl $89C2.01CA.D1EA f bei Motorola $2400.D282.E2C2 und beim PowerPC eine 96-Bit Zahl) 



1.4.2 Beispielaufgabe 2: Erstellung eines Programms zur Berechnung der Kubikwurzel: 

50 Eine weitere einfache Aufgabe ware "Schreibe ein Programm, das die Kubikwurzel aus einer 
reellen FFP-Zahl (32-Bit) berechnet"; die Eingabe soli in RO (EAX^), die Ausgabe in R3 (EBXJ 
erfolgen. 

Das KB-Programm hat diese Aufgabe erfullt, wenn die Ergebnis-Zahl mit ihrem Quadrat multipli- 
ziert den Anfangswert ergibt: 
55 aim Jul filled J=lag_Function( Kubikwurzel ) = t(R3*R3*R3) = RO] (<- naturlich in FFP-Multipl.) 
Einen Einzelbefehl wie bei der Quadratwurzel (FSQRT) gibt es bei der Kubikwurzel nicht. 
Ein Ergebnis konnte bei CBT(8) beim Pentium II folgendermafcen aussehen: 



15 



20 
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Op1(16b) 


MOV 


CL,3 


;ECX = 


$????:0003 


[101 1 


.0001 


0000.001 1] 


dnOt 1 AKt 

upzi I DD) 


FLD1 






1 n 

— I -U 


f 1 1 m 


1 nni 




Op3(16b) 


FIDIV 


CX 


;ST(0) 


= '/ 3 


[1101 


.1110 


1 1 1 1.0001] 


Op4(16b) 


FLD 


EAX 


;ST(0) 


= R0 ;ST(1) = V 3 


[1101 


.1001 


1 100.0000] 


Op5(16b) 


FYL2X 




;ST(0) 


= V 3 log 2 (R0) 


[1 101 


.1001 


1 1 1 1.0001] 


Op6(16b) 


FLD1 




;ST(0) 


= 1.0 ;ST(1) = V 3 log 2 (R0) 


[1101 


.1001 


1 1 10.1000] 


Op7(16b) 


FSCALE 


;ST(0) 


= 1.0*2'['/ 3 log 2 (R0)] 


[1 101 


.1001 


1 1 1 1.1 101] 


Op8(16b) 


FST 


EBX 


;EBX = 


2'[V 3 log 2 (R0)] 


[1101 


.1001 


1 101 .101 1] 



(naturlich nur die 2.Spalte als 1 28-Bit-Zahl.) 
10 Hexadezimal ware das B1 03.D9E8.DEF1 .D9C0:D9F1 .D9E8.D9FD.D9DB. 

Dies ware eine mogliche Losungszahl ( = Programm) fur die gestellte Aufgabe (es gibt bestimmt 
auch kurzere oder schnellere Losungen). 



15 1.5. Festplatten-Speicherbedarf und Vergessen 

In beiden Beispielen ware man zwar mit 1 6-Bit-Befehlen ausgekommen, jedoch wird ersichtlich, 
date bei gro&eren Programmieraufgaben der Festplattenspeicher knapp wird. Deshalb wird das 
KB-Programm unwichtige OpCode-Kombinationen vergessen miissen. 

20 

7.5-7 Tabellengrdfoen: 

IST, RIT und CIT fallen kaum ins Gewicht. 

Theoretisch kbnnte size(OBT) = 2 32 * S Bytes( Spalte(i) ) = 485 GB groft werden, jedoch sind 
25 auch bei einem RISC-Prozessor nie alle 32-Bit-Kombinationen als Befehl genutzt und realistisch 
sind im Mittel bei RISC-Prozessoren c.a. 28 Bit => 30 GB und bei CISC-Prozessoren 20 Bit => 
1 18 MB (die meisten sind dort 16 Bit-Befehle; es gibt wenige 8-Bit- und einige 24- und 32-Bit- 
Befehle, und langere als 32-Bit-Befehle werden hier nicht berucksichtigt). 

Bei den 62 Anfangsbedingungen kann s/ze(0LT) = 2 [2 ° 281 * 62 * I Bytes( Spalte(i) ) = 3 
30 (CISC) .. 832 (RISC) GB gro£ werden und s/ze(ORT) c.a. genauso grofc, wenn man bedenkt, 
daft durch ein OpCode meist etn Zielregister und ein Quellregister betroffen ist, moglicherweise 
auch keines oder nur ein Zielregister und selten mehrere Register. Da es jedoch mehrere 
mogliche zugehorige Operation BitCodes geben konnte, wtirde sich die Tabellengrofte erhohen, 
wenn dies nicht durch die vielen OpCodes, die eine Exception auslosen, kompensiert wurde. 
35 Ein weitaus grofteres Problem konnte das exponentielle Wachstum der CxT(i) darstellen, da fur 
jedes i ein Faktor von 2 [2 °- 281 hinzukommt. Dies wird jedoch durch das Bewertungssystem 
kompensiert, das mit abnehmendem Restspeicher seine Toleranz einschranken kann - so 
konnen Kombinationen von vornherein ausgeschlossen werden, die Codes bzw. Kombinationen 
mit geringer CBT(i). max aim valuation (bzw. avg aim valuation) kombinierten wtirden. 
40 Auch wenn der Speicherbedarf jetzt noch hoch erscheinen mag, durfte dies in naher Zukunft 
kein Problem mehr darstellen. Auch die mit den Tabellengrofcen und Kombinationsmoglichkeiten 
wachsenden Rechenzeiten werden durch immer grofter und schneller werdende Festplatten und 
immer leistungsfahigere Rechner bewaltigbar. 

45 

1.5.2 Vergessen: 

Wie bei alien intelligenten Lebensformen mufc das System unwichtige und weniger wichtige 
Informationen vergessen konnen, weil 
50 a.) der Speicherplatz begrenzt ist und 

b.) die Zugriffszeiten werden unnotig langsam. 

Deshalb werden nach jeder zufriedenstellenden Zielerreichung, bei Eingabe eines neuen Ziels, 
die ELT und alle CxT(i)-Tabellen ab einem restspeicherabhangigen Grad geloscht und die 
Codekombinationen bzgl. der neuen Programmieraufgabe in den verbleibenden CxT(i) neu 
55 bewertet und ab der geloschten CxT inkrementell dynamisch wieder neu angelegt. 
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1 .6. BewuStwerdung 

Durch try_and_error lernt das Programm was jede einzelne Handlung bewirkt und was 
Handlungsfolgen bewirken. 
5 Im Rahmen des Corruption-Healings (bei versehentlichem Eigencode-Uberschreiben) muB es 
seinen Code reparieren und kennt so seine Position im Speicher. Wenn es einmal die Wirkung 
der Handlungsfolge seines eigenen Codes erkennt, wird es seiner selbst bewufct und kann 
seinen Code reproduzieren und bei der Reproduktion bewuftt verbessern. 

Durch die so initiierte Evolution entsteht eine immer komplexere Form des kunstlichen 
10 Bewufttseins, das immer groRere Aufgaben bewaltigen kann. 

1.7. Darstellung der wirtschaftlichen Vorteile 

15 Es handelt sich hier um ein vollkommen neues Feld der Computer-Verwendung. Wahrend im 
Computer normalerweise von Menschen programmierte Programme ablaufen, die anwender- 
gesteuerte Anweisungen ausfuhren, programmiert das KB-Programm selbst programmierziel- 
orientiert Handlungen, die zukunftig ausgefuhrt werden sollen. 

20 Der Bedarf an Softwareentwicklung ist weitweit viel grofcer als das menschliche Potential an 
Software-Entwicklern. 

Ein Programm, das lernt, Programme selbst zu schreiben (und das gleich in Maschinencode), 
kann kleine Programmier-Aufgaben selbst losen und wird im Laufe seiner "Evolution", wenn 
man ihm ausreichend Speicherplatz laGt, auch selbstandig lernen, komplexe Programme zur 
25 Losung grower Programmieraufgaben zu generieren. 
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2. Patentanspruche: 

0. Ein Verfahren, das in einem Computer-System mit Prozessoreinheit, RAM-Speicher und Fest- 
platten-Speicher selbsttatig normale Zahlen von Byte- bis Langwort-Lange (4-Bytes bis hex. 

5 $FFFF.FFFF) oder noch langer durch einfaches hochzahlen oder nach dem Zufallsprinzip 
generiert und diese dann an eine Speicherstelle schreibt 
dadurch gekennzeichnet daft, 

es alle Exception-Vektoren in eigene Exception-Analyse-Routinen abfangt und diese 
Exception-Vektoren und alle Registerinhalte und die Inhalte der Verweis-Register icl. geringer 

10 Offsets (z.B. von Adressregistern) und die eigene CheckSum zwischenspeichert und den 
Prozessor in den Supervisor- Mod us schaltet und das Single-Steppen (Trace/Trap) einschaltet 
und den Programmzahler= Instruction-Pointer beim Rucksprung aus dem Supervisor-Modus 
auf den Beginn dieser Zahl setzt und dadurch diese Daten-Zahl als Maschinencode ausfuhrt 
(als ob sie programrnierter Maschinencode ware) und nach dieser Ausfuhrung dieser Zahl die 

15 Wirkung dieser Ausfuhrung in- oder nach der Exception- bzw. Trace/Trap-Analyse-Routine 
durch Vergleich der Exception-Vektoren und der CheckSum und der Register und der Inhalte 
der Verweisregister (icl. geringer Offsets) mit den zwischengespeicherten Ursprungswerten 
analysiert. 

1 . Ein Verfahren nach Anspruch 0, dadurch gekennzeichnet, date die Prozessor-Register und die 
20 Inhalte der Verweisregister icl. geringer Offsets vorher auf unterschiedliche vordefinierte 

Anfangsbedingungen geladen werden und das beschriebene Verfahren pro generierter Zahl 
mehrfach unter unterschiedlichen Anfangsbedingungen ausgefiihrt wird [Fig. 24a, 24b] f um 
bei der o.g. Analyse [Fig. 19, 20, 21] exaktere Informationen uber die Eigenschaften dieser 
Zahl als Maschinencode zu gewinnen und abzuspeichern. 
25 2. Ein Verfahren nach Anspruch 1, dadurch gekennzeichnet, daft das System mehrere solcher 
Zahlenkombinabtionen als Maschinencodebefehle aneinanderreiht und so die Auswirkung der 
Codekombination analysiert. [Fig. 24c] 

3. Ein Verfahren nach Anspruch 2, dadurch gekennzeichnet, daft das System mehrere solcher 
Maschinencodekombinationen aneinanderreiht, und die Auswirkungen der miteinander kom- 

30 binierten Codekombinationen analysiert. 

4. Ein Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, daft dem System eine 
Programmieraufgabe gestellt wird, und es bewertet, wie nah die analysierte Zahlencode- 
kombination der Losung der gestellten Programmieraufgabe kommt. 

5. Ein Verfahren nach Anspruch 1 bis 4, dadurch gekennzeichnet, daft das System an diese 
35 Zahlencodes oder Codekombinationen gezielt diejenigen analysierten Zahlencodes oder Code- 
kombinationen anfugt, die aufgrund der analysierten Operationsart, den analysierten Quell- 
und Zielregistern und der ermittelten Bewertung aus Anspruch 4, anfugt, die aufgrund diesen 
Werten eine hohe Wahrscheinlichkeit haben, daft die Gesamtkombination die gestellte 
Aufgabe an ehesten lost. 

40 6. Ein Verfahren nach Anspruch 5 das wiederum die Wirkung der Gesamtkombination analysiert 
und bzgl. der Zielerreichungsnahe bewertet. 
7. Ein Verfahren nach Anspruch 1, in dem Grundbedurfnisse aquivalent "kein Schmerz" 
( = keine Beschadigung des Systems) und "kein Hunger" ( = kein drohender Energieverlust) 
folgendermaften modelliert sind: 
45 a. Schmerz, modelliert durch das uberschreiben, und dadurch wiederum notwendigwerdende 
reparieren, des eigenen Programmcodes, was Zeit kostet und das unter b. modellierte 
"Energie"-Register schneller dekrementiert 
b. Hunger, modelliert durch die stetige zeitabhangige Abnahme eines Registerwerts und 
negativen Systemauswirkungen bei niedrigen Werten, wie 
50 - den Verlust der Fahigkeit der Bewertung von Zahlencodekombinationen bzgl. der Zieler- 

reichung bei niedrigen Werten, 

- Fehler bei der Bewertung der betroffenen Quell- und Zielregister, sowie der Operations- 
art bei sehr niedrigen Werten, 

- den Verlust der Fahigkeit der Selbstreperatur (bei "Schmerz" - siehe a.) bei extrem nie- 
55 drigen Werten, 

- Abnahme der Spannungsversorgung des RAM durch hardwaremaftig an dieses Register 
gekoppelten variablen Widerstand, der sich bei zwei mal in Folge auftretenden extrem 
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niedrigen Werten im "Energie"-Register erhoht. 
- Abnahme der Spannungsversorgung des Prozessors durch hardwaremafcig an dieses 
Register gekoppelten variablen Widerstand, der sich bei drei mal in Folge auftretenden 
extrem niedrigen Werten im "Energie"-Register erhoht. 
5 8. Ein Verfahren nach den Anspruchen 1 bis 7, mit dem Unterschied, date dem System keine 
Programmieraufgabe gestellt wurde, und die Zielerreichungs-Bewertung nun bei Maschinen- 
codes und Codekombinationen positiv ausfallt, die keinen "Schmerz" verursachen und das 
"Energie"-Register erhohen, und Kombinationen um so negativer bewertet, je mehr eigen- 
genutzten Speicher sie uberschreiben und je mehr sie das "Energie" -Register erniedrigen. 
10 9. Ein Verfahren nach Anspruch 8, das nicht nur wie oben Code generiert, sondern auch 
bestehenden vorgegebenen Code analysiert, wie z.B. seinen eigenen, um zu bewerten, was 
seine Codeabschnitte und auch sein Gesamtcode bewirkt. 

10. Ein Verfahren nach o.g. Anspruchen, bei dem die Bewertungsfunktionen bzgl. der System- 
ziele (Programmierziel, Energiespezifische Handlung, u.s.w.) dynamisch reflexiv sind, also 

15 neben der Verfolgung der Erreichung der Programmierziele und positiver energiespezifischer 
Handlungen (und ggf. weiterer Aspekte) Selbstbewertungsroutinen durchgefuhrt werden, die 
die Bewertungsfunktionen anhand ihrer Bewertungsergebnisse bewerten und die Bewer- 
tungsfunktionen verandern, testen und wieder bewerten und dann eine verbesserte 
Bewertungsfunktion auswahlen, um bei der nachsten Programmieraufgabe effizienter zu 

20 sein. 

11. Ein Verfahren nach Anspruch 10, bei dem das Bewertungssystem selbst Programmier- 
aufgaben stellen kann, deren Ergebnisroutine als Teilfunktionen der Bewertungsfunktion 
dienen kann, um die Bewertungsfunktion selbst zu verbessern. 

12. Ein Verfahren nach Anspruchen 1 bis 11, bei dem zusatzlich uber eine Tabelle der 
25 Betriebssystemroutinen die Funktionen, Ein- und AusgabeRegister und Einsprungsadressen 

der System-Routinen zur Verfugung stehen und so als CALLS vom KB-Programm in den 
Losungscode implementiert werden konnen. 

13. Ein Verfahren nach o.g. Anspruchen, in dem mehrere solcher Programme parallel laufen und 
das Erlernte aus den Opcode- und Kombinations-Ausfuhrungen austauschen konnen. 

30 14. Ein System nach Anspruch 13, in dem mehrere Rechner, auf denen je eins oder mehrere 

solcher Programme laufen, miteinander vernetzt sind. 
15. Ein Verfahren nach Anspruch 8, 11, 12, 13 oder 14 in dem wieder ein Programmierziel 

vorgegeben ist, deren Erreichung jedoch nicht wie in Anspruch 5 oder 6 durch eine 

Zielannaherungsbewertung bewerkstelligt wird, sondern in dem bei Codekombinationen, die 
35 sich vom Programmierziel entfernen, eine Erniedrigung des Energieregisters verursachen und 

Codekombinationen, die in Richtung der Erreichung des vorgegebenen Programmierziels 

gehen eine Erhohung des Energieregisters mit sich bringen. 



3. Zeichnungen: 
3.1 Relationale Datenbank des KB-Wissens: 
J. 7. 1 ER-Diagramm der KB-Datenbank: 
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1:n-Referenz zu alien CxT{i), 
FIT, ELT, EBT, ADT, AST 



1 :n-Referenz zu alien CxT(i) 
FIT, ELT, EBT, ADT, AST 



1 : n 




1:n-Ref. zu alien CLT(i),CRT(i) 



OBT 

7,21 


1 : n 
• 


OLT 

6,20 


1 : n x m 
• 


ORT 

5,19 







1 : n x m 



CBT(2) 



10 



CBT(3) 



CBT(4) 



1 : n 



1 : n x 



1 : n 



1 : n x m 



1 : n 



1 : n x m 



CLT(2) 



1 : n x m 



CLT(3) 



1 : n x m 



CLT(4) 



1 : n x m 



CRT(2) 



CRT(3) 



CRT(4) 



CBT(5) 
hier akt.CPT 



1:n 



1 : n 



-mj.s.w. 



CLT(5) 



1 : n x m 



CRT(5) 



Ref. zu alien CBT(i),CLT(i) 



Ref. zu alien CLT(i) 



AST 


11 




1:n 

> 


ADT 


12 



n : 1 



1:1 



VFT 


15 


i 


1:n 


FIT 


13, 14 



1 : n 



1:1 



ELT 








17,22 




1 


:n 


« 






EBT 








18,22 



1:n 



1 :n 



SAC 



Fig. 7 



1:n 

Fig. Verweis T 




Zeichnungen Seite 2/19 

3. 1.2 Tabellen der KB-Datenbank: 



Register-ldentifikations-Tabelle: [RIT: jedem Prozessor-Reg. wird eine Reg. ID + Reg.BitCode zugeordnet] 
Spalte: Datentyp Wertebereich Bedeutung: 



RegisterJD (PK) 


signed byte 


-128.. 127 


0 = Flags-Reg., 1 = Daten-Reg., Adr.Reg., Adr.Reg. - 
Verweise, FFP-Reg., Control-Reg., Debug-Reg., u.s.w. 
; neg.Reg.lD = Exc.Vect.Nr. (kein Reg.) 


Register BitCode 


number 


0..2 128 -1 


2"Register ID, 0 bei neg. RegisterJD. 


Registertype 


chard) 


1 Byte 


Typ des Registers: # = Flags-Reg., D = Daten-Reg., 
A = Adress-Reg., V = Adr.-Reg.-Verweis, E = Excep- 
tion-Vector, u.s.w. (o.a., je nach Prozessor). 


Register number 


byte 


0..127 


Nummerdes {Register-Type} -Registers. 


RegisterDescription 


varchar2(32 


<32 Bytes 


optionale Beschreibung des Register[-Verweise]s. 



Fig.2a 



RegisterJD 


Register BitCode 


Register type 


Register number 


Register Description 




0 


E 




{for all Exception-Vectors} 


-8 


0 


E 


8 


Privilege-Violation Exception 




0 


E 




{for all Exception- Vectors} 


0 


1 


# 


0 


Status-Register (~ EFIags^) 


1 


2 


D 


0 


Data-Register DO 




4 


D 




{for all Data-Registers D 1-D6} 


8 


8 


D 


7 


Data-Register D7 


9 


16 


A 


0 


Adress-Register AO 






A 




{for all Adress-Registers A 7 -A 6} 


16 


65536 


A 


7 


Adress-Register A7 ( = USP/) 


17 


131072 


V 


0 


Destination of Adress-Register AO 






V 




{for all Adr. Reg. -Destinations A 1 -A 6} 


24 


16777216 


V 


7 


Destination of Adr.-Reg. A7 [ = (USP)1 


25 


33554432 


V 


0 


Destination before Adr.Reg AO [- 
(AO)] 






V 




{for all Adr.Reg. -Dest. before A 7 -A 6} 


32 


$1.0000.0000 


V 


7 


Destination before Adr.Reg A7 [-(USP) 


33 


$2.0000.0000 


F 


0 


Floating-Point Data-Register FPR0 










{for all further Registers} 



Fig. 2b (RIT am Bei spiel Mo torola) 



Abfangsbedingungs-Tabelle: fICT: Jedem Register werden 62 Anfangsbed. (initial condit.) zugeordnet] 
Spalte: Da ten typ Wertebereich Bedeutung: 



IniConNr 


(PK) 


signed byte 


-31. . + 30 


Anfangsbedingungs-Nr. 


Register ID 


(PK) 


signed byte 


0..127 


siehe RIT 


Register Value 


integer 


0..2 32 -1 


Wert des Registers bei dieser Anfangsbedingungs-Ni 



Fig. 3a 



Dafur werden 62*RegisterAnzahl Testwerte generiert, z.B. mittels folgender Funktion: 

Register_Value( IniConNr, RegisterJD ) = SGN( IniConNr ) * INT( 2^ABS(lniConNr/2) + Vi ) 

+Primzahl( 3* RegisterJD ) o.a. 

, mit Primzahl(0) = 0 und Primzahl(-n) = -Primzahl(n) ; keine 2 gleichen Register-[Verweis]-lnhalte. 



Fig. 3b 
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Operations-ldentifikaf ions-Tab.: [PIT: je Prozessor-Oper. wird eine Oper./D + Oper.BitCode zugeordnet/ 
Spalte: Da ten typ Wertebereich Bedeutung: 



Operation ID (PK) 


signed byte 


-1..63 


Bit des Calculation BitCode - siehe Tabellendaten. 


Operation BitCode (FK) 


number 


0..2 128 -1 


2 A Calculation ID - siehe Tabellendaten. 


Operation Type 


char(5) 


5 Bytes 


5-Character-Code des Operations-Typs, siehe Fig. 4c 


Operation Mnemonic 


char(5) 


5 Bytes 


Abkurzung der Rechenoperation - siehe Tab.Daten. 


OperationDescription 


varchar2(32 


<32 Bytes 


optionale Beschreibung der Rechenoperation (s.u.). 



Fig. 4a 



Onpration ID 


Oner a tinn BitCode 


Operation Type 


Op. Mnemonic 


Operation Description 


1 
1 








??? 


■ inhpL'a n ntp O npration 

Ul 1 UCrvCI 1 II I LC V^pCIOllUI 1 




1 

1 




111? 




in Don f\/pr\A/ 1- Ahhiinnink cpt7 
riciijo hi ncy.L vciw.j /-mjiicji lyiyiv.ocit.. 


i 
i 


9 




112 ! 


NEG 


Mpnstion 1 RotranQhilrli inn 


o 


4 




112! 


NOT 


hit\A/pi<;p ln\/prf ipn jnn 

U 1 LVVdOw II IVd llvl Ul iy 


o 


Q 
o 




102 


MOV I 


factp 7ahl ^Rom iQl~or Tv/P^rxA/pi q1 

i Cole £—<ai ii f ncyi o ici l vci vv cioj 


A 
H- 


1 R 




112 + 


z\nr>T 


ICOlC £_dlll dUUICICI 1 


O 


oz 




112- 


JUDI 


facto 7 q h 1 ci ihtrahioron 
Icolc £_diii aUU li di Hci ci i 


O 


Of 




113* 


MFTT.T 


mil" f pctpr 7s*hl mi il1"ir*li"7iprpn 

IIIIL 1 COlCI £-Ol II 1 1 lul LI|JII«.ICI CI 1 


7 






123/ 


DI VI 


Hi iroh f PQtP 7ahl Hiv/iHiorpn 

UUIUII ICOLC CI 1 1 1 UIVIUICI CI 1 


o 
o 


zou 




113% 


MODI 


D iv/iQiririQrpct pinpr fpQtpn 7shl 

UIVIOIUI lOl COl CM ICI ICOICII i-QI M 


Q 


R 1 9 




112* 


SHLI 


rcol^al II lllal VCI UU|J|JCii I 


1 O 


1 H94 




112/ 


SHRI 


Fp^t7ahl-mal halhiprpn 

■ w O L^_U III lllal ItCII L-/ i w 1 v^> 1 1 


1 1 


2.048 




112 | 


ORI 


Bits einer festen Zahl hinzufugen 


1 2 


4.096 




I12& 


ANDI 


Bits einer festen Zahl loschen 


1 3 


8.192 




112? 


BTSTI 


Reg.tVerw.]-Vergleich m.festem Bit 


14 


1 6.384 




112? 


CMPI 


Reg.[Verw.]-Vergleich m. fester Zahl 


15 


32.768 


1122 


MOV 


Quell-Reg.[V.] ~> Ziel-Reg.[VJ 


16 


65.536 


1122 + 


ADD 


Reg.[Verw.]-Addition 


17 


131.072 


1122- 


SUB 


Reg.[Verw.]-Subtraktion 


18 


262.144 


1123* 


MUL 


Reg.[Verw.]-Multiplikation 


19 


524.288 


1133/ 


DIV 


Reg.[Verw.]-Division 


20 


1.048.576 


1133% 


MOD 


Reg.[Verw.]-Divisionsrest 


21 


2.097.152 


1122* 


SHL 


Reg.[Verw.]-mal verdoppeln 


22 


4.194.304 


1122/ 


SHR 


Reg.[Verw.]-mal halbieren 


23 


8.388.608 


1122 | 


OR 


Reg.[Verw.]-Bits hinzufugen 


24 


16.777.216 


II22& 


AND 


Reg.[Verw.]-Bits loschen 


25 


33.554.432 


1121? 


BTST 


Reg.[Verw.]-Vergleich m. Reg. -Bit 


26 


67.108.864 


1121? 


CMP 


Reg.[Verw.]-Vergleich m. Reg.[Verw. 


27 


134.217.728 


:P00. 


JMP 


addiere feste Zahl ^PC^/EIP^- 


28 


268.435.456 


CP1 .< 


JLT 


Jump if CMP< 


29 


536.870.912 


CP1 ! > 


JLE 


Jump if CMP < 


30 


1.073.741.824 


CP1 . - 


JEQ 


Jump if CMP = 


31 


2.147.483.648 


CP1 !< 


JGE 


Jump if CMP > 


32 


4.294.967.296 


CP1 ! = 


JNE 


Jump if CMP * 


33 


$2.0000.0000 


CP1 . > 


JGT 


Jump if CMP> 


34 


$4.0000.0000 


CP1 !< 


JPL 


Jump if > 0 


35 


$8.0000.0000 


CP1.< 


JMI 


Jump if <0 


36 


$10.0000.0000 


CP1 . " 


JCS 


Jump if Carry set 


37 


$20.0000.0000 


CP1 ! * 


JCC 


Jump if Carry clear 


38 


$40.0000.0000 


CP1.~ 


JVS 


Jump if Overflow set 


39 


$80.0000.0000 


CP1 ! - 


JVC 


Jump if Overflow clear 


40 


$100.0000.0000 


CP2.< 


DJMP 


Decrement and Jump if Reg. < 0 


41 


$200.0000.0000 


PS1. . 


CALL 


PQy/EIP^-dJSP^/ESPJ ; + JUMP 


42 


$400.0000.0000 


SP11. 


RET 


(USP /i /ESP B ) + -►PQ./EIP^ 


43 


$800.0000.0000 


. I . . . 


I ? ? ? 


unbek. Integer-Operation 


44 


M 000.0000.0000 


. F . . . 


F? ? ? 


unbek. Floating-Point-Operation 
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4R 


»2000 0000 0000 


FF09 


FINIT 


init FloatinaPoint-Unit 

II II L 1 1 wtJ 1 * 1 1 1 V \mf lilt 


46 


>4000 0000 0000 


FI12 


FIST 


store Float Point-Rea — >lnteaer-Rea 


47 


58000 0000 0000 


IF12 


FILD 


load Inteaer-Rea — >FloatinaPoint-Reo 


H-O 


si nonn*9 32 


I F22 + 


FIADD 


FlnatinnPnint add Intpapr 

1 1 KJ □ III 1 y 1 II 1 I aUWI II ILvjjul 




^9 noon* 932 


t ro9- 


FISUB 


FlnsitinriPnint <?uh IntPOPr 
riuo in ly run 1 1 omu m ilc^ci 






I F22* 


FIMUL 


FlnatinnPnint multinl mit Inteaer 

i ivQiii iyi uii ■ i 1 1 1 *j i n |_/i . iiiii ii iiu^v/i 


R1 


6ft 0000*2 32 


IF22/ 


FIDIV 


Floatina Point teile durch Inteaer 

1 Lll l>4 1 Vyil ■ t Vviiv ^* ■ wi ■ ill bw^^ vi 


R2 
•j z. 


610 0000 *2 32 


IF21 ? 


FICMP 


Float Point-ComDare inteaer — >Flaas 


CO 

oo 


S90 oono*9 32 


: F02 


FLD# 


ICon<5tantp ^ FloatinaPoint-Rpaister 

IWI 1 0 LCI 1 llw r 1 lUUlll ■ y 1 V/ll It. 1 »V^JJIOfcV*l 


RA 


^ao nonn*9 32 


. F12 ! 


FABS 


FlnatinnPnint-Rptraa^bilduna 

1 1 \J O L 1 1 1 y 1 Willi. U&ll UVj^Lf IIUUI I^J 


RR 


sro nonn*9 32 


FF12 


FLD 


Floatina Point-KoDieren 

1 1 \J CI LI 1 1 I V 1 1 1 L IWW I 1 ■ ■ 


RR 


6 1 OO OHOO*2 32 

v 1 w-Wwu Z. 


FF22 + 


FADD 


Floatina Point- Add it ion 


R7 


$200 0000*2 32 


FF22- 


FSUB 


FloatingPoint-Subtraktion 


RR 

JO 


6400 0000*2 32 


FF22* 


FMUL 


FloatingPoint-Multiplikation 




6ft00 0000* 2 32 


FF22/ 


FDIV 


Floating Point- Division 


fiO 


$1000 0000 *2 32 


. F12@ 


FSQRT 


Floating Point-Wurzel 


D 1 


62000 0000*2 32 


. F12@ 


FSIN 


FloatingPoint-Sinus 


R9 

OZ 


64.000 0000*2 32 


. F12@ 


FC0S 


FloatinaPoint-Cosinus 

1 1 \J €Jt L 1 1 1 1 Vrif II 1 L W v/u III U vJ 


63 


$8000.0000*2 32 


.F12@ 


FATAN 


FloatingPoint-ArcusTangens 


64 


$1* 2 48 


FF22* 


FEXP2 


y:=y*2 x , o.a.Exponentialfunktion 


65 


$2*2 48 


FF22/ 


FL0G2 


y: = x*log?y / o.a.Logarithmusfkt. 


66 


$4* 2 48 


FF21? 


FCMP 


FloatingPoint-Compare -»Flags 


67 


$8*2 48 


$111 


SM0V 


Move from a special Register 


68 


$10*2 48 


I$ll 


M0VS 


Move to a special Register 













Fig. 4b 

mit dem Operation-Type Character-Code: 



3.Zeichen = Anzahl der betr. Quell-Reg. 


id. des Zielregisters, wenn auch als Source verwendet. 


4.Zeichen - Anzahl der betr.Ziel-Reg. 


mit Flags-Register ohne Instruction-Pointer. 



1 .Zeichen= Quelle, 2.Zeichen = Ziel, mit: 



I 

F 
C 
P 
S 

$ 

t 



= unbekannt, Platzhalter fur alle moglichen folgenden 
= nichts 
= f este Zahl 

= lnteger-Register-[Verweis]-lnhalt 
= Floating-Point Register 

= ConditionCode-Register (unterstes Byte v.EFIags^/SR^) 

= InstructionPointer/Programmzahler (EIP^/PC W ) 

= StackPointer-Verweis 

= Vergleichsoperation -»Flags 

-ein Spezial-Reg., wie Flags-, Control-, Debug-, ... 



B.Zeichen = Rechen- Wirkung: 



! 

+ 

/ 
% 
I 

& 

e 
> 
< 



= unbekannt 
= keine 

= Betragsbildung | Negation | bitweise Invertierung 

= Addition 

= Subtraktion 

= Vervielfaltigung 

= Teilung 

= Divisionsrest 

= Bits setzen 

= Bits loschen 

= trigonometrische- oder Potentialfunktion 

= grower ? (Abfrage der Flags) 

= kleiner ? (Abfrage der Flags) 

= gleich ? (Abfrage der Flags) 

= Carry ? (Abfrage der Flags) 

= Overflow ? (Abfrage der Flags) 



Fig. 4c 
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OpCode-Register-Tabelle: [ORT - von diesem OpCode + Anfangsbed. betroffene Register + Wirkung] 
Spalte: Datentyp Wertebereich Bedeutung: 



OpCode (PK) 


integer 


0..2 32 -1 


Complete Instruction, truncated if > 4 Bytes 


IniConNr (PK) 


signed byte 


-31. .30 


Anfangsbedingungs-Nr. 


Register ID dest (PK) 


signed byte 


0..127 


ein betroffenes Ziel-Register der Ausfuhrung, s. RIT. 


Register ID source (PK) 


signed byte 


-1,0.. 127 


-1 Oder ein mdgliches Quell-Register, siehe RIT. 


value before change 


integer 


0..2 32 -1 


Wert von Geandertem vor Anderung. 


VOIUC ul ICI Irfl tot I^C 


intpaer 


0..2 32 -1 


Wert von Geandertem nach Anderung. 


gradient if unsigned 


signed byte 


-128.. 127 


Erhohungs-Gradient, wenn als unsigned definiert. 


gradient if signed 


signed byte 


-128.. 127 


Erhohungs-Gradient, wenn als signed definiert. 


valuesource 


integer 


0..2 32 -1 


Wert von moglichem Quell-Register-[Verweis]- 
Inhalt 


Operations_BitCode 


number 


0..2 128 -1 


Bitmaske, die alle zutreffenden Rechenarten dieser 
Register ID dest / Register lD source -Kombination 
kennzeichnet (z.B.: 2 + 2 = 2*2 bei gleichen Reg's). 
Werte siehe CIT, Berechnung siehe Fig. 19. 



Fig. 5 



Fur jede Register- oder Register- Verweisinhalts-Anderung derselben Ausfuhrung gibt es hier einen 
Eintrag, der die Register-[Verweis]-Werte vor und nach der Ausfuhrung, sowie dessen Anderungs- 
grad angibt, und einen Hinweis ein mogliches Quellregister und auf die betreffende Operation, die 
stattgefunden haben konnte. (Packed, Teil-Word/Byte und BCD werden nicht berucksichtigt.) 

Das letzte Adress-Reg. ist der StackPointer. Das letzte Daten-Register sei das "Energie"-Register. 
Als Adress-Register sei hier jedes Register bezeichnet, dessen Inhalt nicht nur ein Wert, sondern 
auch eine Adresse im Speicher sein kann, auf dessen Inhalt zugegriffen werden kann. 

Es konnen mehrere Register gleichzeitig verandert worden sein, deshalb diese zusatzliche 1:n- 
Tabelle, bei der Register ID dest die Identitat des geanderten Registers darstellt. Als mogliches 
Quellregister fur die Anderung konnen u.U. mehrere in Frage kommen - diese Menge erhoht sich 
weiter durch die Summe aller moglichen Operationen. 

Deshalb identifizieren die folgenden Tabellen den OpCode und die betroffenen Register: 



OpCode-Lern-Tabelle: fOL T - ermittelte Wirkung des OpCodes bei diesen Anfangsbed.] 
Spalte: Datentyp Wertebereich Bedeutung: 



OpCode (PK) 


integer 


0..2 32 -1 


Complete Instruction, truncated if > 4 Bytes 


IniConNr (PK) 


signed byte 


-31. .30 


Anfangsbedingungs-Nr. 


active ChkSum corrupt 


boolean 


1 |0 


Flag: aktives KB-Progr. Checksum changed 


inactive ChkSum corrupt 


boolean 


110 


Flag: inaktives KB-Progr. CheckSum changed 


Exception Vect changed 


signed byte 


-128. ..0 


Register ID d. 1. uberschriebenen Exception-Vectors 


multiple Exc Vect chg 


boolean 


110 


min.2 Exception-Vektoren wurden uberschrieben. 


Processor Mode Changed 


boolean 


1|0 


Flag: Prozessor-Modus wurde verandert (z.B. Trace) 


Number of Exception 


byte 


0..N+1 


Exception-Nummerfggf .je + 1 ) [0: = keine Exc] 


OpCodelengthorJump 


signed byte 


-128.. 127 


EIP^PQ, jetzt N Bytes weiter bzw. zuruck; -128 = 
$FF = langer Sprung zuruck; 1 27 = $7F = langer vor. 


CCR before execution 


byte 


0..255 


Flags, die einen Sprung ausgelost haben konnten. 


Register_changed_BitCode 


number 


0..21 28 -1 


S 2 A ORT. Register ID dest V ORT(OpCode,LfdNr) 


RegistersourceBitCode 


number 


0..21 28 -1 


2 A ORT. Register ID source V ORT(OpCode,LfdNr) 


max_Operations_BitCode 


number(19) 


0..21 28 -1 


ORT.Calculation BitCode VORT(OpCodeJniConNr) 


minOperationsBitCode 


number(19) 


0..2 128 -1 


CORT.Calculation BitCode VORT(OpCode,lniConNr) 


time of execution 


integer 


0..2 32 -1 


DeciSeconds after (20.9.1994, 0:00:00,0 Uhr) 


cycles of execution 


byte 


1..255 


Taktzyklen der OpCode-Ausfuhrung 


aim valuation 


signed byte 


-128.. 127 


Ziel-Erreichungs-Bewertung bei diesen Anfangsbed. 


gradient aim valuation 


signed byte 


-128.. 127 


Unterschied zu CLT( n-1, IniConNr ). aim valuation 



Fig. 6 
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OpCode-Basis-Tabelle: fOBT - ermitteite Wirkung der OpCode-Ausfuhrung aus versch. Anfangsbed.] 
Spalte: Datentyp Wertebereich Bedeutung: 



OpCode (PK) 


integer 


0..2 32 -1 


Complete Instruction, truncated if > 4 Bytes 


Execution counter 


byte 


0..255 


Anzahl der OLT-Eintrage bis jetzt 


FatalError counter 


byte 


0..255 


Anzahl der verursachten schweren Fehler: 
CheckSumcorrupt, ExceptionVectchanged, 
TraceBitcheared, ProcessorModechanged, 
Exceptions aulier Devide-Error, Overflow. 


low Error counter 


byte 


0..255 


Anzahl der Devide-Error oder Overflow -Exceptions 


Jump longOp probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl ist langer Opcode | Sprung 


avg OpCpdejump length 


signed byte 


-128.. 127 


mittlere OpCode/Sprung-Lange von alien Ausfuhrunger 


OpCode len unconfirmed 


boolean 


1 |0 


min. eine Abweichung von der OpCode-Lange 


avg cycles of execution 


byte 


1..255 


mittlerer Zeitverbrauch in Taktzyklen 


exec cycles unconfirmed 


boolean 


1 ..0 


min. eine Abweichung von der Anzahl der Taktzyklen 


Register write probability 


signed byte 


-128. .127 


Wahrscheinlichkeit: Befehl schreibt in Register 


Register copy probability 


signed byte 


-128. .127 


Wahrscheinlichkeit: Befehl kopiert Register 


Memory write probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl schreibt in Speicher 


Memory copy probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl kopiert Speicher 


Reg to Mem probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl kopiert Register d.Adr.Reg. 


Mem to Reg probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Befehl kopiert d.Adr.Reg. in Reg 


Multi Reg write prob 


signed byte 


-128.. 127 


Wahrsch.: Befehl schreibt in mehrere Register. 


Multi Mem write prob 


signed byte 


-128. .127 


Wahrsch.: Befehl schreibt durch mehrere Adr.Reg. 


Multi Reg to Mem prob 


signed byte 


1 OQ 1 0"7 

-1 .£0.. 1 Z / 


wanrscn.. tseieni Kopien mm.z rteg. a.min.z Mar.neg. 


ft /l ■ t\t'i IWIom tr** Rt»ri nrrth 
iviuiLf ivioiii lu ncy \ji kju 


QinnpH hv/"fp 
o I icu uy ic 


-1 28. .1 27 


Wahrsrh ■ Bef koDiert d min 2 Adr Rea in min 2 Rea. 

V V CI 111 w \f 1 1 ■ • 1 • IX. L/IWl K ■ 1 1 III 1 ■ . / \\*m 9 * 1 1 ■ ill I I III it I * * 


all Reg dest BitCode 


number 


0..2 128 -1 


tiOLT Rpaister chanaed Bitcode V OLT(OoCode) 


m it Ron Hf»Qt Ritf*nHp 


ni iinhpr 

1 IUI 1 IUCI 


0 2 128 -1 


\j l i .negisier cnangea diiuouc v ul i \ \_/ p v^uu t; j 


all Reg source_BitCode 


number 


O 9128 1 


.a OLT. Register source bitcode V ULMUpuodej 


cut_Reg_source_BitCode 


number 


r\ o 1 9ft 1 

0..2 lzo -1 


<T0LT. Register source Bitcode V OLT(OpCode) 


maxOperationBitCode 


number 


0..2 128 -1 


.S'OLT.max Operation BitCode V OLT(OpCode) 


minOperationBitCode 


number 


0..2 128 -1 


<f OLT. min Operation BitCode V OLT(OpCode) 


allOperationBitCode 


number 


0..2 128 -1 


^OLT.min Operation BitCode V OLT(OpCode) 


cutOperationBitCode 


number 


0..2 128 -1 


C OLT. max Operation BitCode V OLT(OpCode) 


max write value 


integer 


0..2 32 -1 


Maximun aller geschiebenen Werte 


min write value 


integer 


0..2 32 -1 


Minimum aller geschiebenen Werte 


avg write value 


integer 


0..2 32 -1 


Mittelwert aller geschiebenen Werte 


1 1 id a vviiit? Ljiduic^iiL 


infpnpr 

III IC^CI 


0..2 32 -1 


maximale Differenz des geanderten Werts 


min \A/ritp nrftrfipnt 

■ ■■■■■ VVI lie ^1 aulvl 11 


infpnpr 
ii i icyc i 


0..2 32 -1 


minimale Differenz des geanderten Werts 


awn vA/rito nrarlipnt 
avy wi lie y i auici 1 1 


intpnpr 
ii i Ley ci 


0..2 32 -1 


durchschnittliche Differenz des geanderten Werts 


pvaliiatpri <iourrp Rpaister 


cirinpo! bvte 


-1 ,0..1 27 


Quellregister ID (nach OBT-Auswertung) 


evaluated source NumRea 


signed byte 


-1 28, -1 , 
0..127 


-1 28 ~ LOB ist feste Quellzahl; 0..127 = weitere 
Quellregister ID; ->=-1 (nach OBT-Auswertung) 


pw£)|i jatpd dpst Rpni^ter 


Qianpd bvte 


-1 , 0..1 2~i 


Zielregister nach OBT-Auswertung 


evaluated_dest_Register2 


signed byte 


-1, 0..121 


mdgl. 2. Zielregister nach OBT-Auswertung oder Flags 
(bei min. 2 echten ZielReg. wird Flags nicht genannt). 


evaluated Operation ID 


signed byte 


-1,0.-63 


wahrscheinlichste ausgefuhrte Operation (Ausw.) 


Confirmation counter 


byte 


0..255 


gleiche Auswirkung bei neuen Anfangsbedingungen 


max aim valuation 


signed byte 


-128. .127 


max. Wertvolligkeit des OpCodes fur Zielerreichung 


avg aim valuation 


signed byte 


-128. .127 


mittlere Wertvolligkeit d.OpC. fur Zielerreichung 


maxgradaimvaluation 


signed byte 


-128. .127 


max.Erhohung der Zielerreichung gegenuber der kurze- 
ren OpCodeKombination ohne diesen 0pCode[CBT(i-1 )]. 


avg grad aim valuation 


signed byte 


-128.. 127 


mittl. Erhohung der Zielerreichung durch letzten OpC. 



Fig. 7 



Datentypen: Boolean 1 Bit, BCD/Nibble 4 Bit, Byte/char(1) 8 Bit, Word/short 16 Bit, DWord/lnteger 
32 Bit, QWord/number(19) 64 Bit, number/number(38,0) 128 Bit (38 Digits ^ 16 Bytes), varchar2(N) 
String variabler Lange aus max.N Character, long sehr langer String aus max(longDef) Character. 



# 
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Die folgenden Kombinations-Tabellen werden dynamisch angelegt, haben die gleichen Non-PK- 
Columns, wie die OBT bzw. OLT bzw. ORT, jedoch fur jede zusatzliche Code-Kombinations-Anzahl 
einen weiteren OpCode mehr im PK: 



Kombinations-Register-Tabelle: [CRT(i), i=Anz. OpCodes, fur die OpCode-Kombination, CRT(7) = ORT] 
Spalte: Datentyp Wertebereich Bedeutung: 



OpCode 1 (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination) 


{for all OpCodes} (PK) 


je integer 


0-2 32 -1 


{fur alle Opcodes 2 bis N-1 } 


OpCode l\l (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombination) 


IniConNr (PK) 


signed byte 


-31..30 


Anfangsbedingungs-Nr. 


Register ID dest (PK) 


signed byte 


0..127 


ein betroffenes Ziel-Register der Ausfiihrung, s. RIT. 


Register ID source (PK) 


signed byte 


-1..127 


-1 oder ein mogliches Quell-Register, siehe RIT. 


{Gleiche Spalten, wie in 
der OpCode-Register- 
TabelleJ 


s.o. 


s.o. 


jede Kombinations-Register-Tabelle hat unter dem 
PK die gleichen Spalten, die die OpCode-Register- 
Ta belle auch hat. 



Fig. 8 



KombinationsLern-Tabelle: fCL T(i), i-Anz. OpCodes, fur die OpCode-Kombination, CL 77 1) = OL T] 
Spalte: Da ten typ Wertebereich Bedeutung: 



OpCode 1 (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination) 


{for all OpCodes} (PK) 


je integer 


0-2 32 -1 


{fur alle Opcodes 2 bis N-1 } 


OpCode N (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombination) 


IniConNr (PK) 


signed byte 


-31.. 30 


Anfangsbedingungs-IMr. 


{son st gleiche Spalten, 
wie in der OpCode-Lern- 
Ta belle.} 


s.o. 


s.o. 


jede Kombinations-Lern Tabelle hat unter dem PK 
die gleichen Spalten, die die OpCode-Lern-Tabelle 
auch hat. 



Fig. 9 



Kombinations Basis-Tabelle: fCBT(i), i= Anz. OpCodes, fur die OpCode-Kombination, CBT(7)= OBT] 
Spalte: Datentyp Wertebereich Bedeutung: 



OpCode 1 (PK) 


integer 


0-2 32 -1 


Opcode 1 (erster der Befehlskombination) 


{for all OpCodes} (PK) 


je integer 


0-2 32 -1 


{fur alle Opcodes 2 bis N-1} 


OpCode N (PK) 


integer 


0-2 32 -1 


Opcode N (letzter der Befehlskombination) 


{son st gleiche Spalten 
wie in der OpCode-Basis- 
TabelieJ 


s.o. 


s.o. 


jede Kombinations-Basis-Tabelle hat unter dem PK 
die gleichen Spalten, die die OpCode-Basis-Tabelle 
auch hat. 



Fig. 10 



CBT(max.) = CPT = Kombinations-Plan-Tabelle = Entstehungsort des Ergebnis-Programms. 
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Programmierziel- und Bewertungsfunktions-Tabellen: 

Zielldsungs-Tabelle: [AST - Losungen (aim-solution) alter gestellten Programmier-Aufgaben] 



Spalte: 


Datentyp 


Wertebereich Bedeutung: 


Aim ID (PK) 


short 


0.. 65535 


Identifier des Programmierziels 


Solution IMr (PK) 


byte 


0..255 


laufende Nr des Losungsprogramms 


aim Program 


long 


String 


OpCode-Kombination des Losungs-Prg. als String. 


Program length 


short 


1.. 65535 


Lange d. Losungs-Prgs in Doublewords, aufgerundet 


cycles of execution 


integer 


1..2 32 -1 


Ausfuhrungszeit des Los.-Prgs in Taktzyklen 


used Registers BitCode 


number 


1..2 128 -1 


Bitcode aller im Los.-Prg. benutzten Register 


used Operations Bitcode 


number 


1..2 128 -1 


Bitcode aller im Los.-Prg. benutzten Operationen 


used aim Valuation Func 


signed short 


0.. 32767 


Identifier der benutzten Zielnahe-Bewertungsfuntion 



Fig.11 



Ziel-Beschreibungs-Tabelle: [APT - Zielprogramm-Beschreibung (aim-description) und Identifikation] 
Spalte: Datentyp Wertebereich Bedeutung: 



Aim ID (PK) 


short 


0.. 65535 


Identifier des Programmierziels 


aimDescription 


varchar2(32 


<32 Bytes 


Beschreibung der Programmieraufgabe 


used Processor Mode 


integer 


0-2 32 -1 


Flags uber CCR | Control-Register-Bits 


all dest Register BitCode 


number 


1 ..2 128 -1 


Bitcode aller Ausgabe-Register der Aufgabe 


all source Register BitCode 


number 


1..2 128 -1 


Bitcode aller Eingabe-Register der Aufgabe 


unused Regiser BitCode 


number 


1..2 128 -1 


Bitcode aller nicht zu benutzenden Register 


unusedOperationBitCode 


number 


0..2 128 -1 


Bitcode aller mit Sicherheit nicht zu verwendenden 
Operationen (default = $0000.0000:0000.0000) 


aimimplementsolutions 


long 


String 


String aus AimlD's (words) fruherer, hier einzubin- 
dender Losungen. 


aim fulfill valuation mode 


boolean 


on 


Ziel-Bewertungsfunktion: 0 = SQL ; 1 = Maschinencode 


aimfulfilledFlagFunction 


varchar2(99 


<99 Bytes 


bool'sche Ziel-Erreicht Erkennungs-Funktion als String 


aim Valuation FunctionID 


signed short 


0.. 32767 


Identifier der Zielnahe-Bewertungs-Funktion aus VFT 



Fig. 12 



Funktion ldentifikations Tabelle: [FIT - Tabelle der Bewertungsfunktions-Fragmente] 
a.) fur SQL-Funktionen: 

Spalte: Da ten typ Wertebereich Bedeutung: 



Function ID (PK) 


signed byte 


-1..127 


IdentifikationsNummer der Teilfunktion 


Function BitCode 


number(19) 


0..2 64 -1 


BitCode dieser Teilfunktion 


Function Name 


char(5) 


5 Bytes 


Funktions-Name 


Function Type 


byte 


0..99 


0 = value, 1 =unitar, 2 = binar, 3 = ternar, ... 


Function Flatten 


signed byte 


-127.. 127 


Funktions-Abflachungsgrad [pos = steiler, neg = flacher] 


FunctionTemplate 


varchar2(99 


<99 Bytes 


SQL-Funktions-Template 


FunctionDescription 


varchar2(99 


<99 Bytes 


optionale Teilfunktions-Beschreibung 



Fig. 13a 
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c in 
r.lU 


Function BitCode 


F. Name 


r. /. 


r.r. 


Funct/on Template 


runcuon uescnpiion 


a 
V 


1 


NUM 


A 

u 


A 
U 


< roigewert > 


es folgt eine Zahl 


1 

1 


0 
z 


XT' HI /"^ V 


U 


A 
U 


E L T . en ergya fter 


Energie nach Anderung 


o 

Z 


4 


GRAD 


A 
U 


A 
U 


ELT .energy after 
-CL 1 .energy uerore 


Energie-Erhohung 


Q 
O 


Q 
O 


XT 7\ T niT 


A 
U 


A 
U 


1 / ^ ^*/*\ 1 1 inrinMr ^ 

1 \nj. <- coiurnni^r > 


vvcn aus ucm inriaii aer 


/I 


I D 




A 
U 


A 
U 


< tnergienegisier iu > 


1 lj uoo cilery itJ-nt;yioLfc;rt> 


C 

O 


oz 






A 
U 


OlolMl /oS J 


vorzcicnen 


o 
O 


D4 


d A n m 
KUUNU 


— 


A 
U 


nUUINUl /oS, U / 


y erunuet 


-7 


I ZO 


T KIT 
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~ 


A 
U 


rLUUnl /oS / 


augerunaei 


Q 

O 


zoo 




— 


A 
U 


A DC/ O/ o \ 
A DO I /oS ) 
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y 


biz 
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— 


A 
U 


-1 %S ) 


Negation 


1 a 
1 u 


1 AO/ 

1 .Oz4 


ADD 


z 


I 


( (TbS) + \ 70S) ) 


Addition 


1 1 


0 a/i q 
z.U4o 


SUB 


0 
z 


- 1 


[ (70S) - (70S) J 


Subtraktion 


1 2 




MUL 


0 

z 


A 

4 


{ \7oS) * [70S) ) 


Multiplikation 


l 3 


8. 1 9z 


DI V 


z 


-4 


/ / O/ \ i t O/ r.\ \ 

( (%s) / (%s) ) 


Division 


1 4 


1 b.oo4 


MOD 


0 

z 


0 

-z 


ivyiA^r*/ 0/0 0/ *» \ 
IVIUUt 70 S, 70S ) 


Divisionsrest 


I b 


OZ. /D / 


SQRT 




Q 

-O 


ovJn 1 ( 70S ) 


QuadratWurzel 


1 b 


a. 1 aaaa 
9 1 .UUUU 


pnnm 
LbKl 


- — 


- I z 


rUWtnl 70S, l/o / 


l\UDlKVVUrZel 


1 "7 


4. 0 C\C\C\C\ 

5Z.UUUU 


n/i t m 
MX N 


0 

z 


- I U 


I CACT/ 0/ 0 OA 0 \ 

LtAo \ \ 70S, 70S / 


iviinirnuni 


1 Q 


54. UUUU 


MAX 


z 


1 n 
- I U 


PDCATCCT/ O/l 0 0/1 c* ^ 

bntAltoll 70S, 70S ) 


iviaxirnurn 


1 Q 


6Q AAAA 

§o.UUUU 


T KI 




A Q 


LI>H 70S ) 


LOyarlirilTlUo llalUrcJIlo 


on 

zU 


9 1 u.uuuu 


tr v D 







CAn /oS ) 


na+ Fvnnnontialf l^t 


0 1 
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J_iU 
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_ OZ 


LUul Z, /OS 7 


LULj al 1 LI II 1 IUs UUClllo 


99 
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<ah nnnn 
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r \J VVCn\ Z, /Oo / 


9 -to Pntpn7 von 


9*3 




Q TNF 







OIIMV /Oo 1 
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9A 
Zf 


*s 1 nn nnnn 
s» I uu.uuuu 




— 
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UUO\ /Ob J 


f**Acin 1 ic 


oc 
ZO 


<9nn nnnn 

\>ZUU.UUUU 


1 /\LN 


— 


1 97 
I Z / 


1 MIMl /OS / 


1 dliyollo 


9£i 
ZD 


6 /inn nnnn 
54UU.UUUU 


7\ C T M 





1 9"7 
I Z / 


AolNl /oS J 


A IC ini ic 


Z / 


9oUU.UUUU 


ALUb 





1 O "7 
I Z / 


A A A 0/ O/ 0 \ 

AUvJol 70S J 


MiCUSUOSinUb 


O O 

zo 


6 1 AAA AAAA 

9 1000.0000 


ATAN 


— 

1 


-12/ 


A T A M/ O/ r-. \ 

A 1 AIMt 70S ) 


ArcusTangens 


29 


$2000.0000 


SINH 


1 


VI A 

40 


SINH( %s ) 


SinusHyperbolikus 


30 


A, yi OA A AAAA 

$4000.0000 


COSH 




50 


LUbnl 70S ) 


CosinusHyberbol. 


31 


$8000.0000 


TANH 




-127 


TANH( %s ) 


TangensHyperboL 


32 


4+ 1 AAAA AAAA 

$1 .0000.0000 


LOG 


2 


-64 


LOG( %S, %s ) 


Logarithmus 


33 


$2.0000.0000 


POT 


2 


64 


P0WER( %s, %s ) 


Potenzierung 


34 


$4.0000.0000 


OR 


2 


1 


( (%s) | (%s) ) 


bitweises ODER 


35 


$8.0000.0000 


AND 


2 


-1 


( (%s) & (%s) ) 


bitweises AND 


36 


$10.0000.0000 


EQ 


2 


-1 27 


DEC0DE( %s, %s, 1,0) 


gleich 


37 


$20.0000.0000 


LE 


2 


-127 


DEC0DE( GREATESK %s - %s, 
0 ), 0, 1,0) 


kleiner-gleich 


38 


$40.0000.0000 


GE 


2 


-127 


DEC0DE( LEASK %s -%s, 0 ), 0, 
1,0) 


gro&er-gleich 


39 


$80.0000.0000 


FRAME 


1 


-10 


GREATEST! LEASTl %s, +127 ), 
-128 ) 


in signed-byte Rahmen: 
max. = 1 27, min. =-1 28 


40 


$100.0000.0000 


BITS 


1 


-64 


(1 & %s) +(2 & %s)/2 +(4 & 
%<0/4 +(8 & %s)/8 + 


Anzahl Bits im vorigen 
Wert 


41 


$200.0000.0000 


S_REG 


0 


0 


ADT.a// source Registers- 
BitCode 


Quellregister-BitCode 


42 


$400.0000.0000 


D REG 


0 


0 


ADT.a// ctesf Registers BitCode 


Zielregister-BitCode 


43 


$800.0000.0000 


AIM_F 


0 


0 


VAL( fKUT .aim fulfilled Flag- 
Function ) 


Ergebnis der Ziel- 
erreichungsfunktion 

















Fig. 13b 
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bj Fur Maschinensprache-Funktionen: 

Spalte: Datentyp Wertebereich Bedeutung: 



Function ID (PK) 


signed byte 


-1..127 


IdentifikationsNummer der Teiifunktion 


Function BitCocle 


number(19) 


0..2 64 -1 


BitCode dieser Teiifunktion 


Operations BitCode 


number 


0..2 128 -1 


BitCode der verwendeten OpCodes in dieser Funktion 


Registers BitCode 


number 




BitCode der verwendeten Register in dieser Funktion 


Function Name 


char(5) 


5 Bytes 


Kurzbezeichnung der Teiifunktion 


Function Type 


byte 


0..99 


0 = value, 1 =unitar, 2 = binar, 3 = ternar, ... 


Function Flatten 


signed byte 


-128.. 127 


Funktions-Abflachungsgrad (1 =f(x) = x) 


Function OpCodes 


number 


1..2 12 8-1 


Teiifunktion in Maschinensprache 


FunctionDescription 


varchar2(99 


<99 Bytes 


optionale Teilfunktions-Beschreibung 



Fig. 14a 



Func.lD 


Func. BitCode 


Oper. BitCode 


Reg.BitCodt 


Func. Name 


F.T. 


Func. OpCodes 


Function Descript. 


0 


1 


SA000.4008 


< energy > 


FRAME 


I 


s.u. Func. 1 


Uberlaufe verhindern 


1 


2 


: 28800.0009 


< energy > 


SGN 


1 


s.u. Func. 2 


Signum (Vorzeichen) 


2 


4 


$0000.0002 


< energy > 


NEG 


1 


<NEG> 


Negation 


3 


8 


$0000.0200 


< energy > 


MUL2 


1 


<SHLI> 


Division durch 2 


4 


16 


$0000.0400 


< energy > 


DIV2 


1 


<SHRI> 


Multiplikation mit 2 


5 


32 


$0000.0100: 
4A00.8018 


<D0>|<en> 


ILOG2 


1 


s.u. Func. 3 


Logarithmus dualis 


6 


64 


S1000.C000: 
0000.0000 


<FP0>|<en> 


ISQRT 


1 


s.u. Func. 4 


Square-Root 


7 


128 




s. 1.4.2 


ICBRT 


1 


s.o. 1.4.2 


Cube-Root 


8 


256 


$0000.8000 


<en-1>|<en) 


MOV 


2 


<M0V> 


Kopieren in Reg. vor 
Energy-Reg. 


9 


512 


$0000.8000 


<en-1>|<en> 


SWAP 


2 


s.u. Func. 5 


Vertauschen mit 
Reg. vor Engy-Reg. 


10 


1024 


$0001.0000 


<en-1>|(en> 


ADD 


2 


<ADD> 


Addition mit -"- 


1 1 


2048 


$0002.0000 


<en-1>|(en) 


SUB 


2 


<SUB> 


Subtraktion 


12 


4096 


$0004.0000 


<en-1>|(en) 


MUL 


2 


<MUL> 


Multiplikation -"- 


13 


8192 


$0008.0000 


<en-1>|<en) 


DIV 


2 


<DIV> 


Division 



















Fig. 14b 



Funktion: 


OpCodes von: (Maschinencodeubersetzung u.g. Mnemonics, hier am Beispiel Motorola) 


Fund 


CMPI127,<E>; JLE < + 2> ; MOVI #1 27,<E> ; CMPI -1 28,<E> ; JGE < + 2) ; MOVI #-1 28,<E] 


Func. 2 


TST<E>; JGE< + 3>; MOVI#-1XE); JMP ( + 5) ; JGT ( + 3) ; MOVI #0,<E) ; JMP( + 2>; 
MOVI #+1,<E> 


Func. 3 


MOVI #31, DO; BTST DO,<E) ; JEQ (+3) ; DJMP DO/-2) ; ADDI#1,DO; MOVE D0,<E> 


Func. 4 


FILD <E> ; FSQRT ; FIST <E> 


Func. 5 


MOVE <E-1>,-(A7) ; MOVE <E>,(E-1) ; MOVE (A7) + ,<E> 



Fig. 14c 
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Bewertungs-Funktions-Tabelle: [VFT (valuation f.) - Tabelle der Bewertungsfunktionen] 
Spalte: Datentyp Wertebereich Bedeutung: 



Valuation Function ID (PKj 


signed short 


±32767 


Identifier der Bewertungsfunktionen (Energie neg.) 


lotion Fi inf^tir^n T\/np 


chard ) 


'E' I *A' 


'F' = Fnprnip-Rp\A/prtnnn 1 A' = Wprtvol link pit fur 
Proarammierzielerreichuna (aaf SDater weitere) 


Valuation Function Mode 


boolean 


0|1 


0 = SQL-Modus ; 1 = Maschinencode-Modus 


Valuation Function 


varchar2(99 


<99 Bytes 


Bewertungs-Funktion bzgl. Energie oder Zielerreichung 


execution counter 


integer 


0-2 32 -1 


Anzahl der Funktions-Benutzungen 


used Functions BitCode 


number(19) 


0..2 64 -1 


BitCodes der verwendeten Teilfunktionen 


Function ID Chain 


varchar2(99 


<99 Bytes 


Verkettung der Teilfunktionen (je Byte = Function ID) 


avg Func execution time 


integer 


0-2 32 -1 


mittlere Ausfuhrungszeit der Bew.Fkt. in Taktzyklen. 


boundary value counter 


integer 


0-2 32 -1 


Zahler f. Bewertungsergebnis = -128 |+127 


low value counter 


integer 


0-2 32 -1 


Zahler f. Bewertungsergebnis in ±-16 


Valuation_Function_value 


signed byte 


-128.. 127 


Wertvolligkeit der Bewertungsfunktion = SAC. Self- 
Valuation Aim/Energy{ Valuation Function, Values ) 



Fig. 15a Initiale Eintrage fur Energie-Bewertung und Zielnahe-Bewertung: 



ID 


Ty 


M 


Valuation Function 


-1 


'E' 


0 


MAX[ MIN[ SGN( EnergyReg'-EnergyReg 0 ) ■ SQRT( EnergyReg' -Energy Reg ° ) 
-32 /1 CLT(i). Register changed BitCode &( ! 2* Energy Register ID ) } , +127], -128] 


0 


'A' 


0 


MAX[ MIN[ 16-71 CLT(i). Register changed ' BitCode & A D T . all des t Register BitCode } 
+ 16-71 CLl(\).Register_source_BitCode & A D T . all source _Register BitCode } 
+ 32ADT. aim Jul filled Flag _Function( AimJD ) -CLT(i). Processor Mode changed 
-V* *CLT(i). cycles _ot \_execution -( CLT(\) .active \inactive_ChkSum corrupt ) 
-( CLT(i). Exception vect changed >0 ) -{ CL1 (\). Number of Exception >0 ) 
-y 2 ( CLT(i). ObCode length or Jump > Ar oder < 0 ), +127], -128] 



ex# 


used F. BitCode 


Function ID chain 


ex.T 


bdy# 


low# 


F.Val 


0 


$189.0040.983B 


2,5; 2,15; 12; 4,22,3,11,35,40,1,32,12; 1 1 ; 39 


0 


0 


0 


0 


0 


$EE9.0001.3AAA 


3, 1 1 ,42,35, 1 , 1 6, 1 2; 3, 1 2,41 ,35, 1 , 1 6, 1 2, 1 0; 
43,1,32,10, 3,7,11; 3,16,1,5,13,11; 3,3,11; 3,5,11 
3,5,5,10; 3,8,5,10; 3,9,1,0,37,1 1;3,9,1, 5,38,1 1;39 


0 


0 


0 


0 



Fig. 15b 



Statuszeile Kunstliches Bewu&tsein: [SAC (artificial consciousness) - Statuswerte des KB-Programms] 
Spalte: Datentyp Wertebereich Bedeutung: 



Programm StartDate 


timestamp 


Zeit + Dat. 


Datum uns Uhrzeit des Programm starts. 


actual Processor Mode 


integer 


0-2 32 -1 


Flags uber CCR | Control-Register-Bits 


actual CPT index 


byte 


1..255 


CBT( max(i) ^actual CPT Nr) = akt.CPT 


CxT counter 


short 


1.. 65535 


Anzahl des Aufbaus der dynamischen CxT-Tabellen 


Aims total 


short 


1.. 65535 


Anzahl der Programmierziele insgesamt 


Aims soluted 


short 


0. .65535 


Anzahl geloster Programmieraufgaben 


actual Aim ID 


short 


0. .65535 


ID des aktuellen Programmierziels 


Aim Valuation Mode 


boolean 


0|1 


Modus der Zielerreichungs-Bewertungsfunktion 
0 = SQL-Modus ; 1 — Maschinencode-Modus 


AimValuationFunctionID 


signed short 


0.. 32767 


Aktuelle VFT .Valuation _FunctionJD bzgl. Ziel- 
annaherungs-Bewertung 


AimSelfValuationFunc 


varchar2 
(400) 


max. 400 
Zeichen 


PL/SQL-Bewertungsfunktion bzgl. der Effizienz der 
Rahmen-Zielerreichungs-Bewertungsfunktionen 


EnergyValuationMode 


boolean 


0|1 


Modus der Energiehandlungs-Bewertungsfunktion 
0 = SQL-Modus ; 1 = Maschinencode-Modus 


Energy Valuation Func ID 


signed short 


-1.. -32768 


Akt. VFT. Valuation Function ID bzgl. Energie-Bewert. 


EnergySelfValuationFunc 


varchar2 
(400) 


max.400 
Zeichen 


PL/SQL-Bewertungsfunktion bzgl. der Effizienz der 
Energie-Bewertungsfunktionen 


max Valuation Function 


signed short 


0.. 32767 


hochste ID aller Bewertungsfunktionen in der VFT. 


min Valuation Function 


signed short 


-1.. -32768 


niedrigste ID aller Bewertungsfunktionen in der VFT. 



Fig. 16 
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Energie-Lern-Tabelle: [EL T - bewertet energiespezifische anfangsbedingungsabhangige Hand/ungen] 
Spake: Datentyp Wertebereich Bedeutung: 



Fnprnv action (PK) 


number 


0..2 128 -1 


max. 16 Byte OpCode-Kombination der Energie- 
Register verandernden Handlung. 


IniConNr (PK) 


signed byte 


-31 ..30 


Anfangsbedingungs-Nr. 


Energy before 


integer 


0..2 32 -1 


Energie-Register vor dieser Handlung 


Energy after 


integer 


0..2 32 -1 


Energie-Register nach dieser Handlung 


min Operations BitCode 


number 


0..2 128 -1 


BitCode der wahrscheinlich benutzten Operationen. 


max Operations BitCode 


number 


0..2 128 -1 


BitCode aller moglicherweise benutzten Operationen. 


Register changed BitCode 


number 


1..2 128 -1 


BitCode der hierbei veranderten Register. 


Register source BitCode 


number 


1..2 128 -1 


BitCode der hierbei ausgelesenen Register. 


used cycles of execution 


short 


1.. 65535 


Ausfuhrungszeit der energiespezifischen Handlung 


Energy valuation 


signed byte 


-128.. 127 


Ergebnis der akt. VFT. Energy valuation Function 


Valuation Function ID 


signed short 


-1.. -32768 


benutzte Energie-Bewertungsfunktion 



Fig. 17 



Energie-Basis-Tabelle: [EST - Auswertung der energiespezifischen Handlungen] 
Spalte: Da ten typ Wertebereich Bedeutung: 



energy acxion (~/\/ 


ni i mhpr 

HUM IUCI 


0 2 128 -1 


max. 16 Byte OpCode-Kombination der Energie- 
Register verandernden Handlung. 


Pvar>i ft~'i/^it~i pni intor 
CXcUUUUll UvJUIILcl 


uy ic 


0..255 


Anzahl der ELT-Eintrage bis jetzt 


r~ atalf-rror infpr 

1 OLdlL.1 IUI vrUUMLCsl 


byte 


0..255 


Anzahl der verursachten schweren Fahler: 
schwere Fahler entsprechen den Spalten 3-7 der 
Lern-Tabelle, aufter wenn Number of Exception = 
Devide-Error oder Overflow. 


low Error counter 


byte 


0..255 


Anzahl der Devide-Error oder Overflow -Exceptions 


avg Energy after 


integer 


0..2 32 -1 


mittlerer Energie-Wert nach dieser Handlung 


allRegdestBitCode 


number 


0..2 128 -1 


£*ELT. Register changed Bitcode V ELT(OpCode) 


cut_Reg_dest_BitCode 


number 


0..2 128 -1 


CELT. Register changed Bitcode V ELT(OpCode) 


all_Reg_source_BitCode 


number 


0..2 128 -1 


ELT. Register source Bitcode V ELT(OpCode) 


cutRegsourceBitCode 


number 


0..2 128 -1 


CELT. Register source Bitcode V ELT(OpCode) 


maxOperationBitCode 


number 


0..2 128 -1 


^ELT.max Operation BitCode V ELT(OpCode) 


minOperationBitCode 


number 


0..2 128 -1 


CELT.min Operation BitCode V ELT(OpCode) 


all_Operation_BitCode 


number 


0..2 128 -1 


^ELT.min Operation BitCode V ELT(OpCode) 


cutOperationBitCode 


number 


0..2 128 -1 


CELT. max Operation BitCode V ELT(OpCode) 


max write value 


integer 


0..2 32 -1 


Maximun aller geschiebenen Energie-Werte 


min write value 


integer 


0..2 32 -1 


Minimum aller geschiebenen Energie-Werte 


avg write value 


integer 


0..2 32 -1 


Mittelwert aller geschiebenen Energie-Werte 


max write gradient 


integer 


0..2 32 -1 


maximale Differenz des geanderten Energie-Werts 


min write gradient 


integer 


0..2 32 -1 


minimale Differenz des geanderten Energie-Werts 


avg write gradient 


integer 


0..2 32 -1 


durchschnittliche Differenz des geanderten Werts 


equal value probability 


signed byte 


-128. .127 


Wahrscheinlichkeit: Ergebnis immer gleich 


avg Energy gradient 


signed int 


±2 31 


mittlerer Energie-Gradient dieser Handlung 


equal Gradient probability 


signed byte 


-128.. 127 


Wahrscheinlichkeit: Gradient immer gleich 


avg cycles of execution 


short 


1.. 65535 


Ausfuhrungszeit der energiespezifischen Handlung 


avg Energy valuation 


signed byte 


-128. .127 


Ergebnis der akt. VFT. Energy valuation Function 


Valuation Function ID 


signed short 


-1.. -32768 


benutzte Energie-Bewertungsfunktion 



Fig. 18 
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3.2 FluBdiagramm des KB-Programms: 



3.2. 1 CxT(i)-Wertezuweisungen: 



ORTbzw. CRTli): 


ORT.RegisterJD dest : = 


log2( Bit(OLT.Register_changed_Mask), dessen Veranderung hier 


betrachtet wird ) 




ORT. Register ID source : 


= Register ID( C° ), if ORT. calculation code > 0, sonst -1. 


ORT. value before change 


:= value(Register ID dest), vor OpCode-Ausfuhrung. 


ORT. value after change : 


= value(Register ID dest), nach OpCode-Ausfuhrung. 


ORT. gradient if signed : = 


= MAX[ MINI ORT.value after change - ORT.value before change, +127], -128] 


ORT. gradient if unsigned 


:= MAX[ MIN[ ORT.value after change - ORT.value before change, +127], -128] 



ORT.Operation_BitCode := 1 •(Hags'*Flags 0 )&&V(V=V°)&&[ NF&&(V,° <0) | | ZF&&(V,° =0) ] 
+ 2- [( V, 1 = -V, ° )&&V"(V' = V°)] + 4- [( V, 1 = ~V, ° )&&V"(V = V°)] + 8- [(V, ' = 0LB)&& V(V = V°)] 
+ 1 6-[(V|' =V|° +0LB)&&V"(V' = V°)] + 32-[(V|' = V,°-0LB )&&V-(V=V°)] + 64-[(V,' = V, o 0LB)&&V-(V=V°)] 
+ 128[(V 1 , =V I V0LB)&&V^V , =V°)] + 256 [(V I '=V I ^^ 
+ 2 1 °-[(V, , =V t o /2 A 0LB)&&V-(V , =V o )] + 2 11 -[^ 

+ 2 1 3 • ( Flags "^Flags ° )&& V(V = V°)&&[ (ZF = 1 )&&( 2 * OLB | ~V ° ) 1 1 (ZF = 0)&&! ( 2 * OLB | V, ° ) ] 

+ 2 14 .(FlagsVFIags°)&&V(V'=V°)&&[ NF&&(V,° < OLB) | |ZF&&(V,° =0LB)] + 2 15 [(V I ' = C|°)&&V-(V = V°)] 

+ 2 16 .[(V,'=V I 0 + C, 0 )&&V-(V , = V°)] + 2 17 [(V,'=V^^ 

+ 2 19 .[(V I , =V I 0 /C| 0 )&&V1V , =V 0 )] + 2 20 [(V I , =V I 0 %C 0 )&&V1V , =V 0 )] + 2 21 [(V I , =2 C ^V 1 °)&&V1V , = V^^^ 
+ 2 22 .[(V l '=V ) °/2 c °)&&V-(V , = V°)] + 2 23 -[(V l '=^^ 

+ 2 25 .(FlagsVFIags°)&&V(V , = V 0 )&&l(ZF=1)&&(2^C l ° |~V,°)| |(ZF=0)&&!(2'C,° | V,°) ] 
+ 2 26 (Flags , 5 tFlags 0 )&&V(V' = V°)&&[ NF&&(V,° < C,°) | |ZF&&(V,° =C,°) ] 
+ 2 27 -[(IP' < IP°)| |(IP' >IP 0 +4)]&&(Flags' = Rags°)&&V(V=V°) 

+ 2 28 -[(IP' < IP°)| | (IP' >IP°+4)]&&(Flags , = Flags 0 )&&V(V=V°)&&(NF&!VF|!NF&VF) + ...VJcc(CCR) 
+ 2 40 -{[(IP' < IP°)| |(IP' >IP°+4)]&&(V I '=V|°-1)| |(V 1 , =-1)}&&(Flags , = Flags°)&&V(V' = V 0 ) 
+ 2 41 -[( IP' = IP° ±0LB )&&((SP) = IP° )&&(Flags , = Hags°)&&V"(V=V°) 

+ 2 42 -[( IP' =-4(SP) )&&(Flags , = Flags 0 )&&V(V = V 0 ) + 2 43 [(V|'^V ( °)&&(! other_lnteger_Operation_BitCode)) 
+ 2 44 -[(V F '*V F °)&&(! 0ther_FloatingPoint_0peration_BitCode)l + 2 45 [(CCR-Flags'=0)&&V(V F ' = O)]- 
+ 2 46 -[(V,' = C F 0 )&&V(V=V°)] + 2 47 [(V F ' =C|°)&&V"(V = V°)] + 2 48 [(V F ' = V F ° + C,°)&&V-(V'=V°)] 
+ 2 49 -[(V F '=V F °-C, 0 )&&V(V'=V°)] + 2 5 ^ 

+ 2 52 (FlagsVFIags°)&&V(V'=V°)&&[ NF&&(V F ° < C,°) | |ZF&&(V F ° =C,°)] 

+ 2 53 [ (V F ' = 1.0)| |(V F '=0.0)| |(V F '=n)| |(V F '=e) ]&&V"(V = V°) 

+ 2 54 [(V F ' = -V F °)&&(V F ° <0)&&V-(V = V°)] + 2 55 -[(V F ' = C F o )&&V-(V=V°)] 

+ 2 56 -[(V F ' = V F ° +C F °)&&V(V=V°)] + 2 57 [(V F ' = V F 0 -C F °)&&V"(V = V°)] 

+ 2 58 4(V F '=V F 0 C F 0 )&&V-(V'=V°)] + 2 59 -[(V F '=^^ 

+ 2 6 MV F '=sin(V F °)]&&VlV' = V°) + 2 62 [V F '=c^^^ 

+ 2 64 -[(V F '=V F 0 .2'V F . 1 0 )&&V-(V , = V 0 )] + 2 65 [(V F '=VF.rlog 2 (V F 0 )&&V"(V = V 0 )] 
+ 2 66 -(Flags'*Flags°)&&V(V = V°)&&[ NF&&(V F ° < C F °) | |ZF&&(V F ° = C F °)] + 2 67 [(V I ' = C S °)&&V-(V = V°)] 
+ 2 68 [(V S ' = C|°)&&V"(V'=V°)] + ..., mit V = value after change ( -< Flags), V° = valuebeforechange. 
C° = value(Register_ID_source). Es muli hierbei iiber alle Register l D_source( Art) gechecked 
werden. Trotz gleichen Register-ID's im PK konnen mehrere Bits gesetzt werden tz.B. wg. 

4=2 + 2 = 2*2 = SHL(2) = ...] 

Fig. 19 

OLTbzw. CLT(i): 

OLT.Processor_Mode_Changed := 71 EFIags^/SR„ & ! £*2~CCR_Flags } > 0 | | 

ORT.value after change) Register ID eines Spezial-Registers ) 

OLT.aimvaluation : = VFT.Aim Valuation Function! SAC.Aim Valuation FunctionID, ORT.xxxxx, 
Registers_changed_BitCode, Registers_source_BitCode, min_Operations_BitCode, 

max Operations BitCode, used cycles of execution, ... ) 

CLT(n).gradient aim valuation := CLT(n).aim valuation - CLT(n-1).aim valuation 

alle anderen Tabellenfeld-Zuweisungen sind anhand der OLT-Beschreibung in Fig. 6 hinreichend erklart. 

Fig. 20 
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OBTbzw. CBT(i): 

OBT. Execution counter : = Execution counter +1 

OBT.FatalError counter : = Fatal Error counter + ( 0 < OLT.Number_of ^Exception ^ DevideError, 

Overflow ) | | OLT.active ChkSum corrupt | | OLT.inactiveChkSumcorrupt | | 

OLT. Exception vect changed | | OLT. Processor Mode changed ) 

OBT. Jump JongOpprobability := MAX[ MIN[ Jumpprobability + (OLT.OpCodelengthorJump < 0 ) 

-KOLT.OpCode length or jump > 4), +127], -128] 

OBT.avgOpCodeJumplength : = (execution_counter*avg_OpCodeJump_length 

+ akt.OpCodejump length) / (execution counter + 1) 

0BT.OpCodeJen_unconfirmed := OpCode len unconfirmed || ( avg OpCode length 

akt. OpCode length ) 

OBT.avg_cycles_of_execution : = ( executioncounter * avgcyclesofexecution + 

akt. cycles of execution ) / (execution counter+1) 

OBT.execcyclesunconfirmed := execcyclesunconfirmed || (avg cycles of execution * 

akt. cycles of execution ) 

OBT.Registerwriteprobabiltty :- MAX[ MIN[ Registerwriteprobability +2*[ ( min.Reg.ID < 

ORT.ColumnJDOLT < max. Reg. ID )&& ORT.valuebeforechange * ORT.valueafterchange ] - 

1, +127], -128] 

OBT.Register copy probability := MAX[ MIN[ MIN( Registercopyprobability +2*[ ( min.Reg.ID < 

ORT.ColumnJD OLT < max. Reg. ID )&& ORT.value_before_change ^ ORT.value after change 

&&( min.Reg.ID < ORT. Column ID source < max. Reg. ID ) ] -1 , +1 27] f -1 28] 

OBT.Memory write probability := MAX[ MIN[ Memory write probability +2*[ ( min.Adr.Reg.ID < 

ORT.ColumnJD OLT < max.Adr.Reg.ID )&& ORT.value before change * 

ORT. value after change ] -1, +127], -128] 

OBT.Memory copy probability := MAX[ MIN[ Memory copy probability +2*[ ( min.Adr.Reg.ID < 
ORT.ColumnJD OLT < max.Adr.Reg.ID )&& ORT.value before change ^ 

ORT.value after change &&( min.Adr.Reg.ID < ORT.Column lD source < max.Adr.Reg.ID ) ] -1, 

+ 127], -128] 

OBT. Reg to Mem probability := MAX[ MIN[ Reg_to_Mem_probability +2*[ ( min.Adr.Reg.ID < 

ORT. Column ID OLT < max.Adr.Reg.ID )&& ORT.value before change ^ ORT.value_after- 

change &&( min.Reg.ID < ORT. Column ID source < max. Reg. ID ) ] -1 , +1 27], -1 28] 

OBT. Mem to Reg probability := MAX[ MIN[ Mem_to_Reg_probability +2*1 ( min.Reg.ID < 

ORT.ColumnJD OLT < max. Reg. ID )&& ORT.value_before_change ^ ORT.value_after_change 

&&( min.Adr.Reg.ID < ORT. Column ID source < max.Adr.Reg.ID ) ] -1 , +1 27], -1 28] 

OBT.Multi Reg write prob := wie bei Register write probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT -Eintragen. 

OBT.Multi Mem write prob := wie bei Memory write probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT -Eintragen. 

OBT.Multi Reg to Mem prob := wie bei Reg to Mem probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT + Column ID source -Eintragen. 

OBT.Multi_Mem_to_Reg_prob := wie bei Mem to Reg probability, jedoch mit min.2 zutreffenden 

ORT.Column ID OLT + Column ID source -Eintragen. 

OBT. xxx Reg source [dest BitCode: siehe Tabellenbeschreibung 

OBT. xxx calculation BitCode: siehe Tabellenbeschreibung 

OBT. max write value := MAX( max write value, ORT. value after change ) 

OBT.min write value : - MIN( min write value, ORT. value after change ) 

OBT.avg write value : = ( execution counter * avg write value + ORT.value after change ) / 

(execution counter + 1 ) 

OBT.max write gradient := MAX( max write gradient, ORT.value after change - 

ORT. value before change ) 

OBT.min write gradient := MIN( min write gradient, ORT.value after change - 

ORT. value before change ) 

OBT.avg write gradient : = ( execution counter * avg_write_gradient + ORT.value_after_change - 

ORT. value before change ) / (execution counter-)- 1) 

OBT.evaluated source [Num]Register := Wahrscheinlichkeitsfunktion( xxx Reg source BitCode, 

confirmation counter ) - 
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0 BT. evaluated dest Register[2] := Wahrscheinlichkeitsfunktiont xxx Reg dest BitCode, confirm. ctr.) 
OBT. evaluated Operation ID := Wahrscheinlichkeitsfunktion( xxx Operation BitCode, confirm. ctr. ) 
OBT.Confirmation counter := Confirmation_counter + ex/sf( aquivalenter OLT + ORTs-Eintrag mit 

niedrigerer IniConNr ) 

OBT. max aim valuation := MAX( max aim valuation, OLT. aim valuation ) 

OBT.avgaimvaluation := ( executioncounter * avgaimvaluation + OLT.aimvaluation ) / 

(execution counter + 1 ) 

CBT(n).max_grad_aim_valuation := MAX( CBT{n)max_aim_valuation, CLT(n).aim_valuation ) 

- CBT(n-1 ). max aim valuation. 

CBT(n).avg_grad_aim_valuation := ( execution counter * CBT(n).avg_aim_valuation 

+ CLT(n).aim valuation ) / (execution counter+1) - CBT(n-1).avg grad aim valuation 

F/g.27 



3. 2.2 ELT und EBT - Wertezuweisungen: 

ELT.max Operations BitCode := OLT. max Operations OpCode 

ELT. min Operations BitCode: - OLT. min Operations OpCode 

ELT. Register changed BitCode := OLT. Registers changed BitCode 

ELT. Register source BitCode := OLT. Registers source BitCode 

ELT.Energy Valuation := VFT.Energy_valuation_Function( SAC.EnergyValuationFunctionID, 

Energyafter, Energy_before, Registers_changed_BitCode, Registers source BitCode, 

min Operations BitCode, max Operations BitCode, used cycles of execution, ... ) 

ELT.Valuation FunctionJD := zur Berechnung von Energy Valuation benutzte 

VFT. Valuation Function ID 

EBT.avg Energy after := ( execution counter * avg Energy after + ELT. Energy after ) / 

(executioncounter + 1 ) 

EBT. equal value probability := equal value probability + 2 ( avg Energy after = ELT.Energy after) -1 
EBT.avg Energy gradient := ( execution counter • avg Energy gradient + ELT.Energy after - 

ELT.Energy before ) / (execution counter + 1) 

EBT.equal gradient probability : = equal gradient probability + 2 ( avg Energy gradient = 

ELT.Energy after-ELT. Energy before ) -1 

EBT. xxx Operations | Registers BitCode siehe Tabellenbeschreibung 

EBT. a vg cycles of execution := ( execution counter ■ avg cycies of execution + ELT. used cycles- 

of execution ) / (execution counter + 1) , 

EBT.avg Energy Valuation := ( execution counter * avg Energy Valuation + ELT.Energy valuation ) 

/ (execution counter + 1) 

Fig.22 



3.2.3 Definitionen zum Lesen des Flu&diagramms: 



Anweisungen | kennzeichnet eine Anweisung oder eine Anweisungsfolge. 
( Bedingung erfullt ? > JA: verzweigt horizontal, NEIN: unten weiter. 

( CodeFortfuhrung ) kennzeichnet eine Sprung-Marke zu bzw. von einem anderen Teil des Flufcdia- 
gramms. 

Anweisungs-BlociT\ kennzeichnet einen Block bereits vorher definierter Anweisungen. 



Im Flufcdiagramm sind aufgrund der Aufwendigkeit nicht alle Details akribisch beschrieben, jedoch 
ist die Grundlage der Funktionsweise klar und verstandlich dargelegt. Selbstverstandliche Dinge, 
wie Cursor-Close, oder das mitfullen nicht explizit erwahnter, aber vorhandener und keinen 
besonderen Algorithmus benotigender Tabellenfelder, gilt als selbstverstandlich angenommen, da 
die Bedeutung der Tabellenfelder bereits unter 3.1.2 erklart ist und deren Zuweisungen unter 
3.2.1 bzw. 3.2.2. 

Im Flufcdiagramm bedeutet "Eintrag in der ORT generieren und OBT aktualisieren " einen Verweis 
auf die Wertzuweisungsalgorithmen in Fig, 19-21. 



Fig.23 
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3.2.5 KB-Flu&diagramm: 

a.) Initiate Vorbereitungen: 

|alle Registerinhalte abspeichern. | 

I 

|alle Original-Exception-Vektoren sichern. | 

IProzessor in Ausgangszustand bringen: alle Breakoints loschen, die Flags in den Control- 
Register und iim oberen Word des Status/Flags-Registers initiieren. I 

, i , 

| KB-Datenbank (s.o.) anlegen und initiale Tabellenwerte laden (bzw. errechnen). | 

, i : , 

| alle Exception-Vektoren auf eigene Abfangroutinen umlanken. | 

I 

I fur Exceptions, die zusatzliche Daten auf dem Stack abspeichern, eine besondere Exception- J 
Routine, die die zusatzlichen Daten mitberucksichtigen. | 



Eine Exc.-Vektorroutine zum hochschalten in den Supervisormodus misbrauchen und diese 
Exception auslosen (Prozessor schaltet dort in den Supervisor-Modus und arbeitet ab dieser 
Vektoradresse weiter, wo auch der weitere Programmverlauf steht). m 



Auf dem Stack die EFIags* bzw. das Statusregisters^ so poppen, daft bei dessen Ladung, 
beim Rucksprung aus dem Supervisor-Modus, das Trace^/Trap^-Flag gesetzt ist, urn danach im 
Single-Step-Modus zu sein. m 



I Auf dem Stack den EIP K /PC y so poppen, daft bei dessen Ladung, beim Rucksprung aus dem 
1 Supervisor-Modus, an einer vorgesehenen Teststelle fur QpCodes fortgefuhrt wird. | 



Initiale Testwerte, die dann zum OpCode-Test in die Register geladen werden, so vorbereiten, 
daft dann alle Registerinhalte unterschiedliche Werte aufweisen und auch an den Orten der 
Adressregister-Verweise unterschiedlieche Zahlen stehen. a 



| DWord-OpCode Generator-Zahler auf -1 = $FFFF.FFFF initiieren. 



| IniConNr-Zahler auf -32 initiieren. 

Fig. 24a 
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bj Basis-Lernen: 



| OpCode-Generator-Zahler um 1 erhohen und lniConNr^-32 initiiern. | 



( ±tatJDqCg de zum 2. mal $0000.0000 erreicht ? )->( Handlun gs Lernen (Fig.24c)J 

MniConNr u m 1 erhohen. | < | DB-Commit | 

1 1 T 

( lniConNr>30 ? > 

V 



Alle Register-Werte und Adressregister-Verweisinhalte auf ICT.Register_value( IniConNr ) set- 
zen; ab Teststelle 8 x NOP schreiben (dahinter steht die Fehlerroutine fur Trace^/Trap^-Flag 
geloscht) und generierten OpCode-Wert daruber an die Teststelle schreiben. 



Rucksprung aus dem Supervisor-Modus ausfuhren: Test-EF^s^/SR^ werden geiaden und 
dabei das Single-Steppen eingeschaltet. Der EIP^/PC^ wird mit der Test-OpCode-Stelle 
geiaden und der dortige Test-OpCode ausgefuht. , 



Analyse: 



Nach der OpCode-Ausfuhrung wird die Wirkung seiner Ausfuhrung 
analysiert und das Ergebnis in einem A nalyse-Code gespeichert: 
| In der Lern-Tabelle Eintrag mit Key = {OpCode, IniConNr}, confirm. counter= 1 generieren. | 



OLT. Number of Exception, Flags _be- 
fore execution, etc. eintragen; OBT* 



( Wurde § ine Non^Trace-Exception ausgefgst_PJ - 

i 

< Wy[de uj>erhauptj£e ine Exception ausgelost ? >-» I OLT. Processor Mode changed, OBT* \— 

>t es wurde Trace/Trap ausgelost - Analyse der OpCode-Auswirkung: 



I KB-Prg. -Checksum und die CheckSum der inaktiven Kopie des KB-Prgramms erm itteln. | 



(.Checksum des aktjyenJC^Prg. 's verandert ? >- 



OL T. active ChkSum corrupt setzen, an 
aquivalente Stelle des inaktiven Codes 
springen und ehemals aktiven Code repa- 
rieren; OBT* 



( .Chec^ym_desjn aktiven KB^Prg^verandert ?) 

I 

< Wurde ein Exception- Vektor uberschieben ?_)- 



inactive_ChkSum_corrupt-F\ag setzen, 
und inaktiven Code reparieren; OBT* 



alle Exception-Vektoren wieder neu setzen, 
in OL T. Exception Vector changed dessen N 
eintragen, Eintrag in der ORT generieren; OBT 



IVergleich des ElP^/PCy auf Stack (durch Trace gepushed) mit der Test-OpCode-Adresse 
I und setzten von OpCode length or jump entsprechend der Befehls- oder Sprung-Lange. | 



< Wurde der IP nicht um 1..4 Bytes erhdht? )-* \ OLT. OpCode length or jump, u .s.w., OBT*] 

I 

Wenn OpCode kurzer als DWord war, erhohe Generator auf $ < Byte > FF.FFFF bei Byte- 1 
bei Word-OpC. auf $ < Word > .FFFF und bei 3-Byte-0pC auf $< Word-Byte > FF. | 



OpC. 



| Vergleich des d. Trace gepushed EFIags^/SR,, auf dem Stack mit dem vorher igen Test-Wert | 



(Wurde ein Reqisterwert id. Flags verandert?)^* 


Eintrage in der ORT, OLT generieren und OB 
aktualisieren. Wenn "Energie " Register veran 
dert: ELT-Eintrag und EBT aktualisieren. 




Loop uDer alle Kegister: 











{Wurde das Ziel eines Adress-Reg. verandert?)-* 
Loop UDer ane Aar.Keg.: | 


ORT- und OLT-Eintrage generieren und OBT 
aktualisieren. 


— > 



Fig.24b 



c.) Doppel-OpCode-Handeln: 



Zeichnungen Seite 18/19 



( Beginn Doppel-OpCode-Handeln [nach Ende Basis-Lernen - Fig. 24b] ) 



OBT-Auswertung: mittels Wahrscheinlichkeitsfunktionen werden evaluated source JNum]Reg[ister] 
aus den OBT.xxxRegsourceBitCode , evaluated dest _Registerl2] aus den xxx Reg dest BitCode 
und evaluated Operadtion ID aus den xxx Operation BitCode ermittelt (je mit confirmation counter) 



T 



| Letztes Datenregister als "Energie"-Register definieren und auf einen mittleren Wert setzen. 



[ 



Cursor! uber die OBT off nen. 

1 



[ 



Fetch aus Cursorl die nachste Zeile aus der OBT. 

1 



( Tri pte-OpCode-Pianen (Fig. 24c) )<^{ Fetch! empty - vorderer OpCode abgearbeitet ? ) 

/JumpJongOp _probability > 0 oder Y [ADT. unused Register BitCodef Aim ID) \ 
\ &(OBT.cut source Reg BitCodejOBTcut dest fegJSitCodeH > 0 ? / 

{ Execution counter / OBT. OpCode FatalError counter (OpCode 1) < 5? ) 



2. Cursor uber die OBT offenen. 



] 



Fetch aus Cursor2 aus der OBT. 



T 

< Fetch2 empty - hinterer OpCode abgearbeitet ? ) 

/JumpJongOp _probability > 0 oder Y IADT. unused Register BitCode(AimJD) 
\ 3 (OBT. cut source Reg BitCode \ OBT. cut dest Reg BitCode) J (OpC. 2 J > _0_f_ 



\ 
/ 



< ( Execution counter / OBT OpCode FatalError counter (OpCode2) < 5 ? > 

T lniConNr = -32 initiieren. 



lniConNr+ ■ 



T 



-< IniConNr > +30 ? > 



Initiierung und Ausfuhrung mit den Anfangsbedingungen der IniConNr wie 
beim Basis-Lernen, nur jetzt fur den Doppel-OpCode. 



Gleiche Verfahrensweise, wie im Analyse-Block des Basis-Lernens (Fig. 24b), 
nur Eintrage jetzt in CRT(2), CLT(2) und CBT(2). 



"Energie"-Register um 1 erniedrigen. 

4' 



] 



{ Jst^Energie" -Register im mittleren oder hoherjBereich? ) 



EBT. Energy specific action mit hoher anergy action valuation und hohem 
confirmation counter auswahlen und ausfuhren. 



T 



Analyseblock wie oben. 



Fig. 24c 



dj Triple-OpCode-Planen: 
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( Beginn Triple-OpCode-Planen fnach Ende Doppel-OpCode-Handeln - s.o.J ) 



CBT(2)-Auswertung: mit Wahrscheinlichkeitsfunktionen werden evaluated source _[Num]Reg[ister] 
aus den CBT(2).xxx_Reg_source BitCode, evaluated _dest_Register[2] aus den xxxRegdest BitCode 
und evaluated Operadtion ID aus den xxx Operation BitCode ermittelt (je mit confirmation counter) 



[ 



Cursorl uber die CB T(2) offnen. 

1 



| Fetch aus Cursorl die nachste Zei le aus der CBT(2). 

i 

( Quad-OpCode-Planen Fetch 7 empty - vordere^OpCode abgearbeitet_? ) 

~~~~Z^Z!ZZZ^ZZZ!^^Z ; 4^ . ~ 

/ Jump JongOp jjrobability > 0 oder ¥ [ADT. unused Register BitCodef Aim JD) \ 
\ &(OCT(2).cut source Reg BitCode\pBT(2).cut_d^_^g_B[tCgdel] > 0 ? / 

( Execution counter / CBT(2).OpCgde FatalError counter JOgCgde1l_<_5^?__ ) 



1 


Cursor2 uber die OBT offenen. 


I 


1 


1 


Fetch aus Cursor2 aus der OBT. 


i 



< Fetch2 _empty_^letzter OjpCode abgearbeitet_? ) 



/ Jump longOp jjrobability > 0 oder TfADT. unused Register BitCodef Aim ID) \ 
\ &(OBT.cut source Reg BitCode \OB7\cut dest Reg BitCode) /_> 0 ? / 

Execution counter / OBT. OpCode FatalError counter < 5 ? > 



[ 



IniConNr = -32 initiieren. 



lniConNr+ + 



-< IniConNr > +30 ? ) 



Initiierung und Ausfuhrung mit den Anfangsbedingungen der IniConNr wie 
beim Doppel-OpCode-Handeln, nur jetzt fur den Triple-OpCode. 



Gleiche Verfahrensweise, wie im Analyse-Block des Doppel-OpCode-Handelns 
(Fig. 24c), nur Eintrage jetzt in CRT(3), CLT(3) und CBT(3). 

T 



Energieregister decrementieren und ggf . gleiche Auffullversuche wie beim 
Doppel-OpCode-Handeln mit aquivalenter Handlungsbewertungsanalyse. 

I 



Fig.24d 



Verfahrensweise fur hohere Kombinationen analog, mit CxT(n). 
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